* [PATCH v5 01/33] powerpc: Turn off CPU_FTR_P9_TM_HV_ASSIST in non-hypervisor mode
From: Paul Mackerras @ 2018-10-08 5:30 UTC (permalink / raw)
To: kvm, kvm-ppc; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <1538976679-1363-1-git-send-email-paulus@ozlabs.org>
When doing nested virtualization, it is only necessary to do the
transactional memory hypervisor assist at level 0, that is, when
we are in hypervisor mode. Nested hypervisors can just use the TM
facilities as architected. Therefore we should clear the
CPU_FTR_P9_TM_HV_ASSIST bit when we are not in hypervisor mode,
along with the CPU_FTR_HVMODE bit.
Doing this will not change anything at this stage because the only
code that tests CPU_FTR_P9_TM_HV_ASSIST is in HV KVM, which currently
can only be used when when CPU_FTR_HVMODE is set.
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
---
arch/powerpc/kernel/cpu_setup_power.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/cpu_setup_power.S b/arch/powerpc/kernel/cpu_setup_power.S
index 458b928..c317080 100644
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ b/arch/powerpc/kernel/cpu_setup_power.S
@@ -147,8 +147,8 @@ __init_hvmode_206:
rldicl. r0,r3,4,63
bnelr
ld r5,CPU_SPEC_FEATURES(r4)
- LOAD_REG_IMMEDIATE(r6,CPU_FTR_HVMODE)
- xor r5,r5,r6
+ LOAD_REG_IMMEDIATE(r6,CPU_FTR_HVMODE | CPU_FTR_P9_TM_HV_ASSIST)
+ andc r5,r5,r6
std r5,CPU_SPEC_FEATURES(r4)
blr
--
2.7.4
^ permalink raw reply related
* [PATCH v5 00/33] KVM: PPC: Book3S HV: Nested HV virtualization
From: Paul Mackerras @ 2018-10-08 5:30 UTC (permalink / raw)
To: kvm, kvm-ppc; +Cc: linuxppc-dev, David Gibson
This patch series implements nested virtualization in the KVM-HV
module for radix guests on POWER9 systems. Unlike PR KVM, nested
guests are able to run in supervisor mode, meaning that performance is
much better than with PR KVM, and is very close to the performance of
a non-nested guests for most things.
The way this works is that each nested guest is also a guest of the
real hypervisor, also known as the level 0 or L0 hypervisor, which
runs in the CPU's hypervisor mode. Its guests are at level 1, and
when a L1 system wants to run a nested guest, it performs hypercalls
to L0 to set up a virtual partition table in its (L1's) memory and to
enter the L2 guest. The L0 hypervisor maintains a shadow
partition-scoped page table for the L2 guest and demand-faults entries
into it by translating the L1 real addresses in the partition-scoped
page table in L1 memory into L0 real addresses and puts them in the
shadow partition-scoped page table for L2.
Essentially what this is doing is providing L1 with the ability to do
(some) hypervisor functions using paravirtualization; optionally,
TLB invalidations can be done through emulation of the tlbie
instruction rather than a hypercall.
Along the way, this implements a new guest entry/exit path for radix
guests on POWER9 systems which is written almost entirely in C and
does not do any of the inter-thread coordination that the existing
entry/exit path does. It is only used for radix guests and when
indep_threads_mode=Y (the default).
The limitations of this scheme are:
- Host and all nested hypervisors and their guests must be in radix
mode.
- Nested hypervisors cannot use indep_threads_mode=N.
- If the host (i.e. the L0 hypervisor) has indep_threads_mode=N then
only one nested vcpu can be run on any core at any given time; the
secondary threads will do nothing.
- A nested hypervisor can't use a smaller page size than the base page
size of the hypervisor(s) above it.
- A nested hypervisor is limited to having at most 1023 guests below
it, each of which can have at most NR_CPUS virtual CPUs (and the
virtual CPU ids have to be < NR_CPUS as well).
This patch series is against the kvm tree's next branch.
Changes in this version since version 4:
- Added KVM_PPC_NO_HASH to flags field of struct kvm_ppc_smmu_info rather
than disabling the KVM_PPC_GET_SMMU_INFO ioctl entirely.
- Make sure the hypercalls for controlling nested guests will fail if
the guest is in HPT mode.
- Made the KVM_CAP_PPC_MMU_HASH_V3 capability report false in a nested
hypervisor.
- Fixed a bug causing HPT guests to fail to execute real-mode
hypercalls correctly.
- Fix crashes seen on VM exit or when switching from HPT to radix,
due to leftover rmap values.
- Removed enable/disable flag from KVM_ENABLE_CAP on the
KVM_CAP_PPC_NESTED_HV capability; it always enables.
- Fixed a bug causing memory corruption on nested guest startup,
and a bug where we were never clearing bits in the cpu_in_guest
cpumask.
- Simplified some code in kvmhv_run_single_vcpu.
Paul.
Documentation/virtual/kvm/api.txt | 19 +
arch/powerpc/include/asm/asm-prototypes.h | 21 +
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 12 +
.../powerpc/include/asm/book3s/64/tlbflush-radix.h | 1 +
arch/powerpc/include/asm/hvcall.h | 41 +
arch/powerpc/include/asm/kvm_asm.h | 4 +-
arch/powerpc/include/asm/kvm_book3s.h | 45 +-
arch/powerpc/include/asm/kvm_book3s_64.h | 118 +-
arch/powerpc/include/asm/kvm_book3s_asm.h | 3 +
arch/powerpc/include/asm/kvm_booke.h | 4 +-
arch/powerpc/include/asm/kvm_host.h | 16 +-
arch/powerpc/include/asm/kvm_ppc.h | 4 +
arch/powerpc/include/asm/ppc-opcode.h | 1 +
arch/powerpc/include/asm/reg.h | 2 +
arch/powerpc/include/uapi/asm/kvm.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 5 +-
arch/powerpc/kernel/cpu_setup_power.S | 4 +-
arch/powerpc/kvm/Makefile | 3 +-
arch/powerpc/kvm/book3s.c | 43 +-
arch/powerpc/kvm/book3s_64_mmu_hv.c | 7 +-
arch/powerpc/kvm/book3s_64_mmu_radix.c | 718 ++++++++---
arch/powerpc/kvm/book3s_emulate.c | 13 +-
arch/powerpc/kvm/book3s_hv.c | 852 ++++++++++++-
arch/powerpc/kvm/book3s_hv_builtin.c | 92 +-
arch/powerpc/kvm/book3s_hv_interrupts.S | 95 +-
arch/powerpc/kvm/book3s_hv_nested.c | 1291 ++++++++++++++++++++
arch/powerpc/kvm/book3s_hv_ras.c | 10 +
arch/powerpc/kvm/book3s_hv_rm_xics.c | 13 +-
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 823 +++++++------
arch/powerpc/kvm/book3s_hv_tm.c | 6 +-
arch/powerpc/kvm/book3s_hv_tm_builtin.c | 5 +-
arch/powerpc/kvm/book3s_pr.c | 5 +-
arch/powerpc/kvm/book3s_xics.c | 14 +-
arch/powerpc/kvm/book3s_xive.c | 63 +
arch/powerpc/kvm/book3s_xive_template.c | 8 -
arch/powerpc/kvm/bookehv_interrupts.S | 8 +-
arch/powerpc/kvm/emulate_loadstore.c | 1 -
arch/powerpc/kvm/powerpc.c | 15 +-
arch/powerpc/kvm/tm.S | 250 ++--
arch/powerpc/kvm/trace_book3s.h | 1 -
arch/powerpc/mm/tlb-radix.c | 9 +
include/uapi/linux/kvm.h | 2 +
tools/perf/arch/powerpc/util/book3s_hv_exits.h | 1 -
43 files changed, 3806 insertions(+), 843 deletions(-)
^ permalink raw reply
* [PATCH] powerpc: Fix HMIs on big-endian with CONFIG_RELOCATABLE=y
From: Benjamin Herrenschmidt @ 2018-10-08 4:08 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, npiggin
HMIs will crash the kernel due to
BRANCH_LINK_TO_FAR(hmi_exception_realmode)
Calling into the OPD instead of the actual code.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This hack fixes it for me, but it's not great. Nick, any better idea ?
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index ea04dfb..752709cc8 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1119,7 +1119,11 @@ TRAMP_REAL_BEGIN(hmi_exception_early)
EXCEPTION_PROLOG_COMMON_2(PACA_EXGEN)
EXCEPTION_PROLOG_COMMON_3(0xe60)
addi r3,r1,STACK_FRAME_OVERHEAD
+#ifdef PPC64_ELF_ABI_v1
+ BRANCH_LINK_TO_FAR(.hmi_exception_realmode) /* Function call ABI */
+#else
BRANCH_LINK_TO_FAR(hmi_exception_realmode) /* Function call ABI */
+#endif
cmpdi cr0,r3,0
/* Windup the stack. */
^ permalink raw reply related
* Re: [PATCH v4 25/32] KVM: PPC: Book3S HV: Invalidate TLB when nested vcpu moves physical cpu
From: David Gibson @ 2018-10-08 2:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <20181005053226.GB3309@fergus>
[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]
On Fri, Oct 05, 2018 at 03:32:26PM +1000, Paul Mackerras wrote:
> On Fri, Oct 05, 2018 at 02:54:28PM +1000, David Gibson wrote:
> > On Fri, Oct 05, 2018 at 02:23:50PM +1000, Paul Mackerras wrote:
> > > On Fri, Oct 05, 2018 at 02:09:08PM +1000, David Gibson wrote:
> > > > On Thu, Oct 04, 2018 at 09:56:02PM +1000, Paul Mackerras wrote:
> > > > > From: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
> > > > >
> > > > > This is only done at level 0, since only level 0 knows which physical
> > > > > CPU a vcpu is running on. This does for nested guests what L0 already
> > > > > did for its own guests, which is to flush the TLB on a pCPU when it
> > > > > goes to run a vCPU there, and there is another vCPU in the same VM
> > > > > which previously ran on this pCPU and has now started to run on another
> > > > > pCPU. This is to handle the situation where the other vCPU touched
> > > > > a mapping, moved to another pCPU and did a tlbiel (local-only tlbie)
> > > > > on that new pCPU and thus left behind a stale TLB entry on this pCPU.
> > > > >
> > > > > This introduces a limit on the the vcpu_token values used in the
> > > > > H_ENTER_NESTED hcall -- they must now be less than NR_CPUS.
> > > >
> > > > This does make the vcpu tokens no longer entirely opaque to the L0.
> > > > It works for now, because the only L1 is Linux and we know basically
> > > > how it allocates those tokens. Eventually we probably want some way
> > > > to either remove this restriction or to advertise the limit to the L1.
> > >
> > > Right, we could use something like a hash table and have it be
> > > basically just as efficient as the array when the set of IDs is dense
> > > while also handling arbitrary ID values. (We'd have to make sure that
> > > L1 couldn't trigger unbounded memory consumption in L0, though.)
> >
> > Another approach would be to sacifice some performance for L0
> > simplicity: when an L1 vCPU changes pCPU, flush all the nested LPIDs
> > associated with that L1. When an L2 vCPU changes L1 vCPU (and
> > therefore, indirectly pCPU), the L1 would be responsible for flushing
> > it.
>
> That was one of the approaches I considered initially, but it has
> complexities that aren't apparent, and it could be quite inefficient
> for a guest with a lot of nested guests. For a start you have to
> provide a way for L1 to flush the TLB for another LPID, which guests
> can't do themselves (it's a hypervisor privileged operation). Then
> there's the fact that it's not the pCPU where the moving vCPU has
> moved to that needs the flush, it's the pCPU that it moved from (where
> presumably something else is now running). All in all, the simplest
> solution was to have L0 do it, because L0 knows unambiguously the real
> physical CPU where any given vCPU last ran.
Ah, I see.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 15/36] dt-bindings: arm: Convert Actions Semi bindings to jsonschema
From: Rob Herring @ 2018-10-07 20:11 UTC (permalink / raw)
To: Andreas Färber
Cc: Mark Rutland, devicetree, Kumar Gala, Grant Likely, Arnd Bergmann,
Tom Rini, Frank Rowand, Linus Walleij, Pantelis Antoniou,
linux-kernel@vger.kernel.org, Bjorn Andersson, Mark Brown,
Geert Uytterhoeven, Jonathan Cameron, Manivannan Sadhasivam,
Olof Johansson, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <c4909f78-bfa1-9253-e436-1159392b45a9@suse.de>
On Sat, Oct 6, 2018 at 5:40 AM Andreas Färber <afaerber@suse.de> wrote:
>
> Hi Rob,
>
> Am 05.10.18 um 18:58 schrieb Rob Herring:
> > Convert Actions Semi SoC bindings to DT schema format using json-schema.
>
> This sounds like the next Yanny vs. Laurel... I fail to see any json. ;)
Read the docs in patch 8.
> Also, it may help my understanding to be CC'ed on the cover letter, too?
Sorry, trying to avoid a huge Cc list.
> > Cc: "Andreas Färber" <afaerber@suse.de>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > .../devicetree/bindings/arm/actions.txt | 56 -------------------
> > .../devicetree/bindings/arm/actions.yaml | 34 +++++++++++
> > 2 files changed, 34 insertions(+), 56 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/arm/actions.txt
> > create mode 100644 Documentation/devicetree/bindings/arm/actions.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/actions.txt b/Documentation/devicetree/bindings/arm/actions.txt
> > deleted file mode 100644
> > index d54f33c4e0da..000000000000
> > --- a/Documentation/devicetree/bindings/arm/actions.txt
> > +++ /dev/null
> > @@ -1,56 +0,0 @@
> > -Actions Semi platforms device tree bindings
> > --------------------------------------------
> > -
> > -
> > -S500 SoC
> > -========
> > -
> > -Required root node properties:
> > -
> > - - compatible : must contain "actions,s500"
> > -
> > -
> > -Modules:
> > -
> > -Root node property compatible must contain, depending on module:
> > -
> > - - LeMaker Guitar: "lemaker,guitar"
> > -
> > -
> > -Boards:
> > -
> > -Root node property compatible must contain, depending on board:
> > -
> > - - Allo.com Sparky: "allo,sparky"
> > - - Cubietech CubieBoard6: "cubietech,cubieboard6"
> > - - LeMaker Guitar Base Board rev. B: "lemaker,guitar-bb-rev-b", "lemaker,guitar"
> > -
> > -
> > -S700 SoC
> > -========
> > -
> > -Required root node properties:
> > -
> > -- compatible : must contain "actions,s700"
> > -
> > -
> > -Boards:
> > -
> > -Root node property compatible must contain, depending on board:
> > -
> > - - Cubietech CubieBoard7: "cubietech,cubieboard7"
> > -
> > -
> > -S900 SoC
> > -========
> > -
> > -Required root node properties:
> > -
> > -- compatible : must contain "actions,s900"
> > -
> > -
> > -Boards:
> > -
> > -Root node property compatible must contain, depending on board:
> > -
> > - - uCRobotics Bubblegum-96: "ucrobotics,bubblegum-96"
> > diff --git a/Documentation/devicetree/bindings/arm/actions.yaml b/Documentation/devicetree/bindings/arm/actions.yaml
> > new file mode 100644
> > index 000000000000..af9345a228b4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/actions.yaml
> > @@ -0,0 +1,34 @@
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/soc/arm/actions.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
>
> 404 for the schema. Where does one find an explanation?
In the docs. This could someday actually be hosted on devicetree.org,
but for now only the path, not the host, matters.
>
> > +
> > +title: Actions Semi platforms device tree bindings
> > +
> > +maintainers:
> > + - Andreas Färber <afaerber@suse.de>
>
> Mani is now officially reviewer and the closest I have to a
> co-maintainer.
Okay, NP.
> I suggest we add him here in some form. I assume this is
> independent of MAINTAINERS patterns though, or will get_maintainers.pl
> parse this, too?
It is independent. Not really ideal, but the bindings don't live just
in the kernel. (And lots are missing a maintainer anyways).
> > +
> > +description: |
>
> Does the | have any meaning, or a stray typo?
Explained in other patch.
> > + The Actions Semi S500 is a quad-core ARM Cortex-A9 SoC. The Actions Semi
> > + S900 is a quad-core ARM Cortex-A53 SoC.
>
> You forgot the S700 as another quad-core Cortex-A53 SoC.
> Also, arm or Arm rather than ARM these days?
I was going to say it's just copied out from the old file, but that
doesn't seem to be the case here. I am sure I didn't spend time on
nice descriptions. :)
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - items:
> > + - enum:
> > + - lemaker,guitar-bb-rev-b
> > + - enum:
> > + - lemaker,guitar
> > + - allo,sparky
> > + - cubietech,cubieboard6
> > + - const: actions,s500
> > + minItems: 2
> > + maxItems: 3
> > + additionalItems: false
>
> Objection. You've managed to turn a perfectly human-comprehensible text
> into a machine-parseable representation incomprehensible for humans.
>
> First, there should remain some free-text explanation of the values
> defined here. Are comments allowed after the value or indented maybe?
Yes, both. Comments are the major reason for using YAML over JSON file format.
> Alternatively we could have a per-vendor file à la vendor-prefixes.txt,
> but that would seem inefficient.
You mean per board vendor files? We'd have to duplicate the SoC
compatibles then as you can't really split the schema to 2 files.
There's 2 SoC families doing per board vendor files: Atmel (only one
vendor though) and i.MX. This series makes those 2 a single file like
all other SoCs. I don't really care which way it is done, but I think
we should be consistent and I'm not going to convert everyone's
bindings to per board vendor files.
> Next, the above items construct is horrible. What about nested oneOf:
>
> + - items:
> + - oneOf:
> + - items:
> + - enum:
> + - lemaker,guitar-bb-rev-b
> + - const: lemaker,guitar
> + - items:
> + - enum:
> + - allo,sparky
> + - cubietech,cubieboard6
> + - const: actions,s500
That's not actually doing what you think. That's saying the first item
is a list of items (1 or 2 items). For example, you'd have to have
data like this to be valid:
[ [ allo,sparky ], actions,s500 ]
(Note that [] are more json style list format, but allowed in yaml too.)
Probably the best thing to do here is separate the 2 and 3 item cases.
That also would eliminate some combinations here that are allowed, but
not valid.
>
> This grouping is much clearer to me and hopefully to anyone adding
> further base boards for the module.
> We will have the same issue for the BPi-S64 module with S700 below.
>
> > + - items:
> > + - const: cubietech,cubieboard7
> > + - const: actions,s700
> > + - items:
> > + - const: ucrobotics,bubblegum-96
> > + - const: actions,s900
>
> Please make the board compatible an enum, even if only one is listed
> today. That makes it clearer where/how (and easier) to add new boards.
Yes, I did that in most cases, but not here some reason.
Rob
^ permalink raw reply
* Re: [PATCH 27/36] dt-bindings: arm: Convert Realtek board/soc bindings to json-schema
From: Rob Herring @ 2018-10-07 19:20 UTC (permalink / raw)
To: Andreas Färber
Cc: Mark Rutland, devicetree, Kumar Gala, Grant Likely, Arnd Bergmann,
Tom Rini, Frank Rowand, Linus Walleij, Pantelis Antoniou,
linux-kernel@vger.kernel.org, Bjorn Andersson, Mark Brown,
Geert Uytterhoeven, Jonathan Cameron, Manivannan Sadhasivam,
Olof Johansson, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <41eb7b19-dd26-16e2-bd80-b8b7d6f52f94@suse.de>
On Sat, Oct 6, 2018 at 5:54 AM Andreas Färber <afaerber@suse.de> wrote:
>
> Am 05.10.18 um 18:58 schrieb Rob Herring:
> > Convert Realtek SoC bindings to DT schema format using json-schema.
>
> YAML (2x)
?
> > Cc: "Andreas Färber" <afaerber@suse.de>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > .../devicetree/bindings/arm/realtek.txt | 22 ----------------
> > .../devicetree/bindings/arm/realtek.yaml | 25 +++++++++++++++++++
> > 2 files changed, 25 insertions(+), 22 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/arm/realtek.txt
> > create mode 100644 Documentation/devicetree/bindings/arm/realtek.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/realtek.txt b/Documentation/devicetree/bindings/arm/realtek.txt
> > deleted file mode 100644
> > index 95839e19ae92..000000000000
> > --- a/Documentation/devicetree/bindings/arm/realtek.txt
> > +++ /dev/null
> > @@ -1,22 +0,0 @@
> > -Realtek platforms device tree bindings
> > ---------------------------------------
> > -
> > -
> > -RTD1295 SoC
> > -===========
> > -
> > -Required root node properties:
> > -
> > - - compatible : must contain "realtek,rtd1295"
> > -
> > -
> > -Root node property compatible must contain, depending on board:
> > -
> > - - MeLE V9: "mele,v9"
> > - - ProBox2 AVA: "probox2,ava"
> > - - Zidoo X9S: "zidoo,x9s"
> > -
> > -
> > -Example:
> > -
> > - compatible = "zidoo,x9s", "realtek,rtd1295";
> > diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml
> > new file mode 100644
> > index 000000000000..9e3bb3249c77
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/realtek.yaml
> > @@ -0,0 +1,25 @@
> > +# SPDX-License-Identifier: None
>
> What is the expected license for such bindings?
Good question. I'd meant to figure something out for this placeholder.
The default would be GPL-2 inheriting from the old doc. My preference
would be to dual license these with BSD as they're not just kernel
files, but I don't really want to track down copyright holders (also
not explicitly declared) to do that.
> You did not add such a line for actions.yaml.
>
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/bindings/arm/realtek.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Realtek platforms device tree bindings
> > +
> > +maintainers:
> > + - Andreas Färber <afaerber@suse.de>
> > +
> > +description: |+
>
> "|+"?
The '|' means a literal block. The '+' is a block chomping indicator:
http://yaml.org/spec/1.2/spec.html#id2794534
This was all converted using my doc2yaml script and ruamel.yaml
decided it needed the '+'. I'm not sure exactly why. It may be based
on how many trailing newlines the text had.
> > + RTD1295 SoC
In this case, this isn't really useful and we should just remove
description unless you want to add something.
> > +
> > +properties:
> > + $nodename:
> > + const: '/'
> > + compatible:
> > + items:
> > + - enum:
> > + - mele,v9
> > + - probox2,ava
> > + - zidoo,x9s
> > + - const: realtek,rtd1295
> > +...
>
> That does not look like a full "PATCH" yet? It also confuses me whether
> or when leading dashes are necessary - for Actions Semi "items" had one.
'...' is the end of YAML document marker.
'-' means a list item (a YAML/JSON list, not to be confused with
'items' the json-schema keyword). Actions uses 'oneOf' (which is a
list of schemas) because there are multiple SoCs.
And also 'items' itself can be a list or dict, but we restrict it to
lists for the DT meta-schema.
> I have preparations on my GitHub staging tree for three more SoCs, so we
> should prepare the structure to ease adding SoCs and avoid re-indenting
> patches - adding SoCs was much easier in the original flat text format.
> Please also consider for other vendors.
Good point.
One option is always use 'oneOf' even if just 1 item. The problem is
that the use of oneOf/allOf/anyOf makes the error reporting pretty
vague.
Another option is to make each SoC a separate schema which could be
either separate docs or multiple yaml docs within a file. The downside
is just repeating all the top-level properties.
>
> Same comment as for Actions: We're losing a human description of the
> enum values.
I kept those as comments when there was meaningful information. I did
not feel that "MeLE V9" as a description of "mele,v9" added any value.
If you want to add 'model' schema that would be better than having
just comments, but I'm not going to find all the values of model which
aren't documented.
Rob
^ permalink raw reply
* Re: [PATCH v5 1/9] book3s/64: avoid circular header inclusion in mmu-hash.h
From: Christophe LEROY @ 2018-10-07 16:43 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87r2h3i6np.fsf@concordia.ellerman.id.au>
Le 06/10/2018 à 14:47, Michael Ellerman a écrit :
> Christophe LEROY <christophe.leroy@c-s.fr> writes:
>
>> The serie has been successfully compiled tested at
>> http://kisskb.ellerman.id.au/kisskb/head/358723b36b126a381d827c82d04ee226321416b2/
>
> I guess we need to turn on BPF_JIT in some configs :)
>
> This works (builds), but not runtime tested:
>
> diff --git a/arch/powerpc/net/bpf_jit32.h b/arch/powerpc/net/bpf_jit32.h
> index 6f4daacad296..dc50a8d4b3b9 100644
> --- a/arch/powerpc/net/bpf_jit32.h
> +++ b/arch/powerpc/net/bpf_jit32.h
> @@ -106,9 +106,8 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
> } while (0)
> #else
> #define PPC_BPF_LOAD_CPU(r) \
> - do { BUILD_BUG_ON(FIELD_SIZEOF(struct thread_info, cpu) != 4); \
> - PPC_LHZ_OFFS(r, (1 & ~(THREAD_SIZE - 1)), \
> - offsetof(struct thread_info, cpu)); \
> + do { BUILD_BUG_ON(FIELD_SIZEOF(struct task_struct, cpu) != 4); \
> + PPC_LHZ_OFFS(r, 2, offsetof(struct task_struct, cpu)); \
> } while(0)
> #endif
> #else
>
Thanks, I'll take that.
Christophe
^ permalink raw reply
* Re: [PATCH v5 3/9] powerpc: Prepare for moving thread_info into task_struct
From: Christophe Leroy @ 2018-10-07 5:31 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87tvlzi6yq.fsf@concordia.ellerman.id.au>
On 10/06/2018 12:40 PM, Michael Ellerman wrote:
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>
>> diff --git a/arch/powerpc/include/asm/livepatch.h b/arch/powerpc/include/asm/livepatch.h
>> index 47a03b9b528b..818451bf629c 100644
>> --- a/arch/powerpc/include/asm/livepatch.h
>> +++ b/arch/powerpc/include/asm/livepatch.h
>> @@ -49,7 +49,7 @@ static inline void klp_init_thread_info(struct thread_info *ti)
>> ti->livepatch_sp = (unsigned long *)(ti + 1) + 1;
>
> We need to do something about this.
Oops I missed that one.
>
> Currently the thread_info sits at the low address of the stack, and we
> use the space immediately above that as a miniature upward growing stack
> for livepatching.
>
> If we keep the livepatch_sp in the thread_info then we need to
> initialise it somewhere when the task starts running on a stack. And I
> don't know how that works if we end up running on the emergency stack
> for example.
>
> So I'm not sure that makes much sense.
>
> Instead we might need to keep the livepatch_sp on the stack page at the
> base, where thread_info currently lives.
>
> That obviously sucks because you can still overflow into it and trash
> it, but it's no worse than what we have now for livepatching.
>
> Need to think about it some more.
>
I think for that serie we can leave with it in the stack, as it won't be
worst than before. Then in a future patch we can change it. I'll open an
issue for that on github.
Then for now, I'll add the following change in this patch.
diff --git a/arch/powerpc/include/asm/livepatch.h
b/arch/powerpc/include/asm/livepatch.h
index 47a03b9b528b..8a81d10ccc82 100644
--- a/arch/powerpc/include/asm/livepatch.h
+++ b/arch/powerpc/include/asm/livepatch.h
@@ -43,13 +43,14 @@ static inline unsigned long
klp_get_ftrace_location(unsigned long faddr)
return ftrace_location_range(faddr, faddr + 16);
}
-static inline void klp_init_thread_info(struct thread_info *ti)
+static inline void klp_init_thread_info(struct task_struct *p)
{
+ struct thread_info *ti = task_thread_info(p);
/* + 1 to account for STACK_END_MAGIC */
- ti->livepatch_sp = (unsigned long *)(ti + 1) + 1;
+ ti->livepatch_sp = end_of_stack(p) + 1;
}
#else
-static void klp_init_thread_info(struct thread_info *ti) { }
+static inline void klp_init_thread_info(struct task_struct *p) { }
#endif /* CONFIG_LIVEPATCH */
#endif /* _ASM_POWERPC_LIVEPATCH_H */
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index d9d4eb2ea6c9..a12307ebb7ef 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1632,7 +1632,7 @@ int copy_thread(unsigned long clone_flags,
unsigned long usp,
unsigned long sp = (unsigned long)task_stack_page(p) + THREAD_SIZE;
struct thread_info *ti = task_thread_info(p);
- klp_init_thread_info(ti);
+ klp_init_thread_info(p);
/* Copy registers */
sp -= sizeof(struct pt_regs);
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 9ca9db707bcb..8054a7b9e026 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -940,7 +940,7 @@ void __init setup_arch(char **cmdline_p)
/* Reserve large chunks of memory for use by CMA for KVM. */
kvm_cma_reserve();
- klp_init_thread_info(&init_thread_info);
+ klp_init_thread_info(&init_task);
init_mm.start_code = (unsigned long)_stext;
init_mm.end_code = (unsigned long) _etext;
Christophe
^ permalink raw reply related
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.19-4 tag
From: Greg KH @ 2018-10-07 5:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: srikar, linux-kernel, joel, linuxppc-dev, herbert
In-Reply-To: <87y3bbi7pf.fsf@concordia.ellerman.id.au>
On Sat, Oct 06, 2018 at 10:24:28PM +1000, Michael Ellerman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi Greg,
>
> Please pull some more powerpc fixes for 4.19:
>
> The following changes since commit 7e0cf1c983b5b24426d130fd949a055d520acc9a:
>
> selftests/powerpc: Fix Makefiles for headers_install change (2018-09-28 15:07:45 +1000)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-4.19-4
Now merged, thanks.
greg k-h
^ permalink raw reply
* [PATCH v4 3/3] powerpc/process: Constify the number of insns printed by show instructions functions.
From: Christophe Leroy @ 2018-10-06 16:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, muriloo
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <981244f0ffb38c1aa02c9eb831c7ebf479b8f564.1538789120.git.christophe.leroy@c-s.fr>
instructions_to_print var is assigned value 16 and there is no
way to change it.
This patch replaces it by a constant.
Reviewed-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v4: rebased
v3: no change
v2: no change
arch/powerpc/kernel/process.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 8dabf656d924..dd8447d3f0bf 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1258,17 +1258,16 @@ struct task_struct *__switch_to(struct task_struct *prev,
return last;
}
-static int instructions_to_print = 16;
+#define NR_INSN_TO_PRINT 16
static void show_instructions(struct pt_regs *regs)
{
int i;
- unsigned long pc = regs->nip - (instructions_to_print * 3 / 4 *
- sizeof(int));
+ unsigned long pc = regs->nip - (NR_INSN_TO_PRINT * 3 / 4 * sizeof(int));
printk("Instruction dump:");
- for (i = 0; i < instructions_to_print; i++) {
+ for (i = 0; i < NR_INSN_TO_PRINT; i++) {
int instr;
if (!(i % 8))
@@ -1301,17 +1300,17 @@ static void show_instructions(struct pt_regs *regs)
void show_user_instructions(struct pt_regs *regs)
{
unsigned long pc;
- int n = instructions_to_print;
+ int n = NR_INSN_TO_PRINT;
struct seq_buf s;
char buf[96]; /* enough for 8 times 9 + 2 chars */
- pc = regs->nip - (instructions_to_print * 3 / 4 * sizeof(int));
+ pc = regs->nip - (NR_INSN_TO_PRINT * 3 / 4 * sizeof(int));
/*
* Make sure the NIP points at userspace, not kernel text/data or
* elsewhere.
*/
- if (!__access_ok(pc, instructions_to_print * sizeof(int), USER_DS)) {
+ if (!__access_ok(pc, NR_INSN_TO_PRINT * sizeof(int), USER_DS)) {
pr_info("%s[%d]: Bad NIP, not dumping instructions.\n",
current->comm, current->pid);
return;
--
2.13.3
^ permalink raw reply related
* [PATCH v4 1/3] powerpc/process: fix casting and missing header
From: Christophe Leroy @ 2018-10-06 16:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, muriloo
Cc: linuxppc-dev, linux-kernel
This patch fixes the following warnings. The first ones are leftovers
from when __get_user() was replaced by probe_kernel_address().
The last one is from when show_user_instructions() was added.
arch/powerpc/kernel/process.c:1287:22: warning: incorrect type in argument 2 (different address spaces)
arch/powerpc/kernel/process.c:1287:22: expected void const *src
arch/powerpc/kernel/process.c:1287:22: got unsigned int [noderef] <asn:1>*<noident>
arch/powerpc/kernel/process.c:1319:21: warning: incorrect type in argument 2 (different address spaces)
arch/powerpc/kernel/process.c:1319:21: expected void const *src
arch/powerpc/kernel/process.c:1319:21: got unsigned int [noderef] <asn:1>*<noident>
arch/powerpc/kernel/process.c:1302:6: warning: symbol 'show_user_instructions' was not declared. Should it be static?
Fixes: 7b051f665c32d ("powerpc: Use probe_kernel_address in show_instructions")
Fixes: 88b0fe1757359 ("powerpc: Add show_user_instructions()")
Reviewed-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v4: no change. Serie rebased on top of latest powerpc/merge (87dbfc1308ee)
v3: new in v3 to fix sparse warnings reported by snowpatch on the serie
arch/powerpc/kernel/process.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index d9d4eb2ea6c9..3396c419abf2 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -65,6 +65,7 @@
#include <asm/livepatch.h>
#include <asm/cpu_has_feature.h>
#include <asm/asm-prototypes.h>
+#include <asm/stacktrace.h>
#include <linux/kprobes.h>
#include <linux/kdebug.h>
@@ -1281,7 +1282,7 @@ static void show_instructions(struct pt_regs *regs)
#endif
if (!__kernel_text_address(pc) ||
- probe_kernel_address((unsigned int __user *)pc, instr)) {
+ probe_kernel_address((const void *)pc, instr)) {
pr_cont("XXXXXXXX ");
} else {
if (regs->nip == pc)
@@ -1323,7 +1324,7 @@ void show_user_instructions(struct pt_regs *regs)
pr_info("%s[%d]: code: ", current->comm, current->pid);
}
- if (probe_kernel_address((unsigned int __user *)pc, instr)) {
+ if (probe_kernel_address((const void *)pc, instr)) {
pr_cont("XXXXXXXX ");
} else {
if (regs->nip == pc)
--
2.13.3
^ permalink raw reply related
* [PATCH v4 2/3] powerpc/process: fix interleaved output in show_user_instructions()
From: Christophe Leroy @ 2018-10-06 16:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, muriloo
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <981244f0ffb38c1aa02c9eb831c7ebf479b8f564.1538789120.git.christophe.leroy@c-s.fr>
When two processes crash at the same time, we sometimes encounter
interleaving in the middle of a line:
[ 4.365317] init[1]: segfault (11) at 0 nip 0 lr 0 code 1
[ 4.370452] init[1]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
[ 4.372042] init[74]: segfault (11) at 10a74 nip 1000c198 lr 100078c8 code 1 in sh[10000000+14000]
[ 4.386829] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
[ 4.391542] init[1]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
[ 4.400863] init[74]: code: 90010024 bf61000c 91490a7c 3fa01002 3be00000 7d3e4b78 3bbd0c20 3b600000
[ 4.409867] init[74]: code: 3b9d0040 7c7fe02e 2f830000 419e0028 <89230000> 2f890000 41be001c 4b7f6e79
This patch fixes it by preparing complete lines in a buffer and
printing it at once.
Fixes: 88b0fe1757359 ("powerpc: Add show_user_instructions()")
Reviewed-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v4: rebased
v3: no change
v2: Using seq_buf and reworked the loop to avoid redundant prints.
arch/powerpc/kernel/process.c | 37 +++++++++++++++++++------------------
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 3396c419abf2..8dabf656d924 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -43,6 +43,7 @@
#include <linux/uaccess.h>
#include <linux/elf-randomize.h>
#include <linux/pkeys.h>
+#include <linux/seq_buf.h>
#include <asm/pgtable.h>
#include <asm/io.h>
@@ -1300,7 +1301,9 @@ static void show_instructions(struct pt_regs *regs)
void show_user_instructions(struct pt_regs *regs)
{
unsigned long pc;
- int i;
+ int n = instructions_to_print;
+ struct seq_buf s;
+ char buf[96]; /* enough for 8 times 9 + 2 chars */
pc = regs->nip - (instructions_to_print * 3 / 4 * sizeof(int));
@@ -1314,29 +1317,27 @@ void show_user_instructions(struct pt_regs *regs)
return;
}
- pr_info("%s[%d]: code: ", current->comm, current->pid);
+ seq_buf_init(&s, buf, sizeof(buf));
- for (i = 0; i < instructions_to_print; i++) {
- int instr;
+ while (n) {
+ int i;
- if (!(i % 8) && (i > 0)) {
- pr_cont("\n");
- pr_info("%s[%d]: code: ", current->comm, current->pid);
- }
+ seq_buf_clear(&s);
- if (probe_kernel_address((const void *)pc, instr)) {
- pr_cont("XXXXXXXX ");
- } else {
- if (regs->nip == pc)
- pr_cont("<%08x> ", instr);
- else
- pr_cont("%08x ", instr);
+ for (i = 0; i < 8 && n; i++, n--, pc += sizeof(int)) {
+ int instr;
+
+ if (probe_kernel_address((const void *)pc, instr)) {
+ seq_buf_puts(&s, "XXXXXXXX ");
+ continue;
+ }
+ seq_buf_printf(&s, regs->nip == pc ? "<%08x> " : "%08x ", instr);
}
- pc += sizeof(int);
+ if (!seq_buf_has_overflowed(&s))
+ pr_info("%s[%d]: code: %s\n", current->comm,
+ current->pid, s.buffer);
}
-
- pr_cont("\n");
}
struct regbit {
--
2.13.3
^ permalink raw reply related
* Re: [PATCH v5 1/9] book3s/64: avoid circular header inclusion in mmu-hash.h
From: Michael Ellerman @ 2018-10-06 12:47 UTC (permalink / raw)
To: Christophe LEROY, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <8055896d-f1cd-3560-2f08-ab367270beae@c-s.fr>
Christophe LEROY <christophe.leroy@c-s.fr> writes:
> The serie has been successfully compiled tested at
> http://kisskb.ellerman.id.au/kisskb/head/358723b36b126a381d827c82d04ee226321416b2/
I guess we need to turn on BPF_JIT in some configs :)
This works (builds), but not runtime tested:
diff --git a/arch/powerpc/net/bpf_jit32.h b/arch/powerpc/net/bpf_jit32.h
index 6f4daacad296..dc50a8d4b3b9 100644
--- a/arch/powerpc/net/bpf_jit32.h
+++ b/arch/powerpc/net/bpf_jit32.h
@@ -106,9 +106,8 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
} while (0)
#else
#define PPC_BPF_LOAD_CPU(r) \
- do { BUILD_BUG_ON(FIELD_SIZEOF(struct thread_info, cpu) != 4); \
- PPC_LHZ_OFFS(r, (1 & ~(THREAD_SIZE - 1)), \
- offsetof(struct thread_info, cpu)); \
+ do { BUILD_BUG_ON(FIELD_SIZEOF(struct task_struct, cpu) != 4); \
+ PPC_LHZ_OFFS(r, 2, offsetof(struct task_struct, cpu)); \
} while(0)
#endif
#else
cheers
^ permalink raw reply related
* Re: [PATCH v5 3/9] powerpc: Prepare for moving thread_info into task_struct
From: Michael Ellerman @ 2018-10-06 12:40 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <65eac9f906b12b55010a00b477619f7739c1cac5.1538687075.git.christophe.leroy@c-s.fr>
Christophe Leroy <christophe.leroy@c-s.fr> writes:
> diff --git a/arch/powerpc/include/asm/livepatch.h b/arch/powerpc/include/asm/livepatch.h
> index 47a03b9b528b..818451bf629c 100644
> --- a/arch/powerpc/include/asm/livepatch.h
> +++ b/arch/powerpc/include/asm/livepatch.h
> @@ -49,7 +49,7 @@ static inline void klp_init_thread_info(struct thread_info *ti)
> ti->livepatch_sp = (unsigned long *)(ti + 1) + 1;
We need to do something about this.
Currently the thread_info sits at the low address of the stack, and we
use the space immediately above that as a miniature upward growing stack
for livepatching.
If we keep the livepatch_sp in the thread_info then we need to
initialise it somewhere when the task starts running on a stack. And I
don't know how that works if we end up running on the emergency stack
for example.
So I'm not sure that makes much sense.
Instead we might need to keep the livepatch_sp on the stack page at the
base, where thread_info currently lives.
That obviously sucks because you can still overflow into it and trash
it, but it's no worse than what we have now for livepatching.
Need to think about it some more.
cheers
^ permalink raw reply
* Re: Looking for architecture papers
From: Segher Boessenkool @ 2018-10-06 12:27 UTC (permalink / raw)
To: Raz; +Cc: linuxppc-dev
In-Reply-To: <CAPB=Z-pW6FWEp=0PgphCo-mAh9pPgt0frjz_MkPp6YHuhX3-pQ@mail.gmail.com>
On Sat, Oct 06, 2018 at 12:19:45PM +0300, Raz wrote:
> Hey
> How does HVSC works ?
> I looked in the code and LoPAR documentation. It looks like there is
> vector called
> system_call_pSeries ( at 0xc00 ) that is supposed to be called when we
> invoke HVSC from kernel
> mode.
> Now, I wrote a NULL call HSVC and patched the exceptions-64s.S to
> return RFID immediately.
> This does not work.
> Would you be so kind to explain how HVSC works ?
> thank you
If your kernel is not running in hypervisor mode, sc 1 does not call the
kernel (but the hypervisor, instead). If your kernel _is_ running in
hypervisor mode, sc 1 does the same as sc 0, a normal system call.
I don't know which it is for you; you didn't say.
I have no idea what "a NULL call HSVC" means. If you make exception c00
return immediately (as you suggest) then you have made all system calls
non-functional, which indeed is unlikely to work as you want.
Segher
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-4.19-4 tag
From: Michael Ellerman @ 2018-10-06 12:24 UTC (permalink / raw)
To: Greg KH; +Cc: srikar, linux-kernel, joel, linuxppc-dev, herbert
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Greg,
Please pull some more powerpc fixes for 4.19:
The following changes since commit 7e0cf1c983b5b24426d130fd949a055d520acc9a:
selftests/powerpc: Fix Makefiles for headers_install change (2018-09-28 15:07:45 +1000)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-4.19-4
for you to fetch changes up to ac1788cc7da4ce54edcfd2e499afdb0a23d5c41d:
powerpc/numa: Skip onlining a offline node in kdump path (2018-10-05 23:21:54 +1000)
- ------------------------------------------------------------------
powerpc fixes for 4.19 #4
Four regression fixes.
A fix for a change to lib/xz which broke our zImage loader when building with XZ
compression. OK'ed by Herbert who merged the original patch.
The recent fix we did to avoid patching __init text broke some 32-bit machines,
fix that.
Our show_user_instructions() could be tricked into printing kernel memory, add a
check to avoid that.
And a fix for a change to our NUMA initialisation logic, which causes crashes in
some kdump configurations.
Thanks to:
Christophe Leroy, Hari Bathini, Jann Horn, Joel Stanley, Meelis Roos, Murilo
Opsfelder Araujo, Srikar Dronamraju.
- ------------------------------------------------------------------
Christophe Leroy (1):
powerpc/lib: fix book3s/32 boot failure due to code patching
Joel Stanley (1):
lib/xz: Put CRC32_POLY_LE in xz_private.h
Michael Ellerman (1):
powerpc: Don't print kernel instructions in show_user_instructions()
Srikar Dronamraju (1):
powerpc/numa: Skip onlining a offline node in kdump path
arch/powerpc/kernel/process.c | 10 ++++++++++
arch/powerpc/lib/code-patching.c | 20 ++++++++++++--------
arch/powerpc/mm/numa.c | 5 +++--
lib/xz/xz_crc32.c | 1 -
lib/xz/xz_private.h | 4 ++++
5 files changed, 29 insertions(+), 11 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAlu4qRMACgkQUevqPMjh
pYDEmRAAg7zDF379BIYZ9cCtyaEsPr1Qozu4qMKlq0cwhNSBNIC6AIjxlYqbRVcX
qmlvfSCfxEXxFOWLVxVxChNtYHTkRnhK0UFus6DszsJcBwxNlJCfXS8ufhOFDlpt
OKBx1bqS3NIiWhSXOzSmwHY9L4o/oyiZKjfk4HJ/7er0woS20bF3pHtXPdsuEjno
dSMftLI5YYKWSKAfsv1z6zSQRdxWOqM3Zd+Zpnvp9oTNSgqPvRFU9JwnGXVbJHOk
mQsJalMCOnbVphW8XnImbtW7TQfkbctmN95rl/OcEVm39QX4UL7suAJih5Z45TIU
mYuXXH6gTahGd4N3RfGUf2QO/3pQOiPOpywuqey/Pa68Bc5b2/fvySQ2sdMhE6yJ
rMfYlXDlFd/xL63d231QR8DiTzSdDHhDUo7T6R12fJK2f/q5Sng6rJj/71o68lun
9v/Jvt/G/Z9w25AUsPO2zlS/rIVP7C7EGknycBe5UwC2DRx7HCtKwFjOb0e2BY23
ysqF3Jpk+TsLBES4ye9vafhhDlGZg/cuej0OWFf0Ca/bi1fV59Hw2XaI3qj+VsFf
psl/DcJE8+EyDUVAVloYaM8yr96QJdH7+I9Ea/8FC4cyJSIAiMzrlrTp/zonzbQl
hbMVjZujVrQiNdbJ+irb7bCpaAPXdP81CK4FSGGyRvJ0Jycnvno=
=u2T9
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v4 0/9] powerpc: Switch to CONFIG_THREAD_INFO_IN_TASK
From: Michael Ellerman @ 2018-10-06 12:21 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1538541946.git.christophe.leroy@c-s.fr>
Christophe Leroy <christophe.leroy@c-s.fr> writes:
> The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which
> moves the thread_info into task_struct.
>
> Moving thread_info into task_struct has the following advantages:
> - It protects thread_info from corruption in the case of stack
> overflows.
> - Its address is harder to determine if stack addresses are
> leaked, making a number of attacks more difficult.
We need to fixup bpf_jit32.h:
#ifdef CONFIG_SMP
#ifdef CONFIG_PPC64
#define PPC_BPF_LOAD_CPU(r) \
do { BUILD_BUG_ON(FIELD_SIZEOF(struct paca_struct, paca_index) != 2); \
PPC_LHZ_OFFS(r, 13, offsetof(struct paca_struct, paca_index)); \
} while (0)
#else
#define PPC_BPF_LOAD_CPU(r) \
do { BUILD_BUG_ON(FIELD_SIZEOF(struct thread_info, cpu) != 4); \
PPC_LHZ_OFFS(r, (1 & ~(THREAD_SIZE - 1)), \
offsetof(struct thread_info, cpu)); \
} while(0)
#endif
#else
#define PPC_BPF_LOAD_CPU(r) do { PPC_LI(r, 0); } while(0)
#endif
cheers
^ permalink raw reply
* Re: powerpc: Don't print kernel instructions in show_user_instructions()
From: Michael Ellerman @ 2018-10-06 12:14 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: jannh, muriloo
In-Reply-To: <20181005132123.6038-1-mpe@ellerman.id.au>
On Fri, 2018-10-05 at 13:21:23 UTC, Michael Ellerman wrote:
> Recently we implemented show_user_instructions() which dumps the code
> around the NIP when a user space process dies with an unhandled
> signal. This was modelled on the x86 code, and we even went so far as
> to implement the exact same bug, namely that if the user process
> crashed with its NIP pointing into the kernel we will dump kernel text
> to dmesg. eg:
>
> bad-bctr[2996]: segfault (11) at c000000000010000 nip c000000000010000 lr 12d0b0894 code 1
> bad-bctr[2996]: code: fbe10068 7cbe2b78 7c7f1b78 fb610048 38a10028 38810020 fb810050 7f8802a6
> bad-bctr[2996]: code: 3860001c f8010080 48242371 60000000 <7c7b1b79> 4082002c e8010080 eb610048
>
> This was discovered on x86 by Jann Horn and fixed in commit
> 342db04ae712 ("x86/dumpstack: Don't dump kernel memory based on usermode RIP").
>
> Fix it by checking the adjusted NIP value (pc) and number of
> instructions against USER_DS, and bail if we fail the check, eg:
>
> bad-bctr[2969]: segfault (11) at c000000000010000 nip c000000000010000 lr 107930894 code 1
> bad-bctr[2969]: Bad NIP, not dumping instructions.
>
> Fixes: 88b0fe175735 ("powerpc: Add show_user_instructions()")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Reviewed-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/a932ed3b718147c6537da290b7a91e
cheers
^ permalink raw reply
* Re: powerpc/numa: Skip onlining a offline node in kdump path
From: Michael Ellerman @ 2018-10-06 12:14 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Pavithra Prakash, Srikar Dronamraju, Mahesh J Salgaonkar,
Hari Bathini, linuxppc-dev, Michael Bringmann
In-Reply-To: <1538106452-7643-1-git-send-email-srikar@linux.vnet.ibm.com>
On Fri, 2018-09-28 at 03:47:32 UTC, Srikar Dronamraju wrote:
> With Commit 2ea626306810 ("powerpc/topology: Get topology for shared
> processors at boot"), kdump kernel on shared lpar may crash.
>
> The necessary conditions are
> - Shared Lpar with atleast 2 nodes having memory and CPUs.
> - Memory requirement for kdump kernel must be met by the first N-1 nodes
> where there are atleast N nodes with memory and CPUs.
...
>
> As part of fix, detect and skip early onlining of a offline node.
>
> Fixes: 2ea626306810 ("powerpc/topology: Get topology for shared processors at boot")
> Reported-by: Pavithra Prakash <pavrampu@in.ibm.com>
> Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> Tested-by: Hari Bathini <hbathini@linux.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/ac1788cc7da4ce54edcfd2e499afdb
cheers
^ permalink raw reply
* Re: linux-next: build failure after merge of the akpm tree
From: Michael Ellerman @ 2018-10-06 12:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux Kernel Mailing List, Linux-Next Mailing List, Andrew Morton,
PowerPC
In-Reply-To: <20181005224606.2372fece@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Michael,
>
> On Fri, 05 Oct 2018 22:02:45 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>> Ah fudge, what are the chances we add a new include of bootmem.h just as
>> Mike's removing bootmem.
>
> In my experience, it was almost certain ... almost every API removal
> conflicts with new added uses. :-)
I suppose. Though the last time we added a new include of bootmem.h was
2015, and that should have actually been memblock.h.
>> I could just apply that to my tree. memblock.h is where early_memtest() is
>> actually defined anyway.
>
> However min_low_pfn and max_low_pfn are defined in bootmem.h until
> after it is removed.
OK. I guess I'll leave it for Andrew to squash in to the series.
cheers
^ permalink raw reply
* Re: [PATCH 27/36] dt-bindings: arm: Convert Realtek board/soc bindings to json-schema
From: Andreas Färber @ 2018-10-06 10:54 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Kumar Gala, Grant Likely, Arnd Bergmann,
Tom Rini, Frank Rowand, Linus Walleij, Pantelis Antoniou,
linux-kernel, Bjorn Andersson, Mark Brown, Geert Uytterhoeven,
Jonathan Cameron, Manivannan Sadhasivam, Olof Johansson,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20181005165848.3474-28-robh@kernel.org>
Am 05.10.18 um 18:58 schrieb Rob Herring:
> Convert Realtek SoC bindings to DT schema format using json-schema.
YAML (2x)
>
> Cc: "Andreas Färber" <afaerber@suse.de>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/arm/realtek.txt | 22 ----------------
> .../devicetree/bindings/arm/realtek.yaml | 25 +++++++++++++++++++
> 2 files changed, 25 insertions(+), 22 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/realtek.txt
> create mode 100644 Documentation/devicetree/bindings/arm/realtek.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/realtek.txt b/Documentation/devicetree/bindings/arm/realtek.txt
> deleted file mode 100644
> index 95839e19ae92..000000000000
> --- a/Documentation/devicetree/bindings/arm/realtek.txt
> +++ /dev/null
> @@ -1,22 +0,0 @@
> -Realtek platforms device tree bindings
> ---------------------------------------
> -
> -
> -RTD1295 SoC
> -===========
> -
> -Required root node properties:
> -
> - - compatible : must contain "realtek,rtd1295"
> -
> -
> -Root node property compatible must contain, depending on board:
> -
> - - MeLE V9: "mele,v9"
> - - ProBox2 AVA: "probox2,ava"
> - - Zidoo X9S: "zidoo,x9s"
> -
> -
> -Example:
> -
> - compatible = "zidoo,x9s", "realtek,rtd1295";
> diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml
> new file mode 100644
> index 000000000000..9e3bb3249c77
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/realtek.yaml
> @@ -0,0 +1,25 @@
> +# SPDX-License-Identifier: None
What is the expected license for such bindings?
You did not add such a line for actions.yaml.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/bindings/arm/realtek.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Realtek platforms device tree bindings
> +
> +maintainers:
> + - Andreas Färber <afaerber@suse.de>
> +
> +description: |+
"|+"?
> + RTD1295 SoC
> +
> +properties:
> + $nodename:
> + const: '/'
> + compatible:
> + items:
> + - enum:
> + - mele,v9
> + - probox2,ava
> + - zidoo,x9s
> + - const: realtek,rtd1295
> +...
That does not look like a full "PATCH" yet? It also confuses me whether
or when leading dashes are necessary - for Actions Semi "items" had one.
I have preparations on my GitHub staging tree for three more SoCs, so we
should prepare the structure to ease adding SoCs and avoid re-indenting
patches - adding SoCs was much easier in the original flat text format.
Please also consider for other vendors.
Same comment as for Actions: We're losing a human description of the
enum values.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 15/36] dt-bindings: arm: Convert Actions Semi bindings to jsonschema
From: Andreas Färber @ 2018-10-06 10:40 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Kumar Gala, Grant Likely, Arnd Bergmann,
Tom Rini, Frank Rowand, Linus Walleij, Pantelis Antoniou,
linux-kernel, Bjorn Andersson, Mark Brown, Geert Uytterhoeven,
Jonathan Cameron, Manivannan Sadhasivam, Olof Johansson,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20181005165848.3474-16-robh@kernel.org>
Hi Rob,
Am 05.10.18 um 18:58 schrieb Rob Herring:
> Convert Actions Semi SoC bindings to DT schema format using json-schema.
This sounds like the next Yanny vs. Laurel... I fail to see any json. ;)
Also, it may help my understanding to be CC'ed on the cover letter, too?
>
> Cc: "Andreas Färber" <afaerber@suse.de>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/arm/actions.txt | 56 -------------------
> .../devicetree/bindings/arm/actions.yaml | 34 +++++++++++
> 2 files changed, 34 insertions(+), 56 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/actions.txt
> create mode 100644 Documentation/devicetree/bindings/arm/actions.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/actions.txt b/Documentation/devicetree/bindings/arm/actions.txt
> deleted file mode 100644
> index d54f33c4e0da..000000000000
> --- a/Documentation/devicetree/bindings/arm/actions.txt
> +++ /dev/null
> @@ -1,56 +0,0 @@
> -Actions Semi platforms device tree bindings
> --------------------------------------------
> -
> -
> -S500 SoC
> -========
> -
> -Required root node properties:
> -
> - - compatible : must contain "actions,s500"
> -
> -
> -Modules:
> -
> -Root node property compatible must contain, depending on module:
> -
> - - LeMaker Guitar: "lemaker,guitar"
> -
> -
> -Boards:
> -
> -Root node property compatible must contain, depending on board:
> -
> - - Allo.com Sparky: "allo,sparky"
> - - Cubietech CubieBoard6: "cubietech,cubieboard6"
> - - LeMaker Guitar Base Board rev. B: "lemaker,guitar-bb-rev-b", "lemaker,guitar"
> -
> -
> -S700 SoC
> -========
> -
> -Required root node properties:
> -
> -- compatible : must contain "actions,s700"
> -
> -
> -Boards:
> -
> -Root node property compatible must contain, depending on board:
> -
> - - Cubietech CubieBoard7: "cubietech,cubieboard7"
> -
> -
> -S900 SoC
> -========
> -
> -Required root node properties:
> -
> -- compatible : must contain "actions,s900"
> -
> -
> -Boards:
> -
> -Root node property compatible must contain, depending on board:
> -
> - - uCRobotics Bubblegum-96: "ucrobotics,bubblegum-96"
> diff --git a/Documentation/devicetree/bindings/arm/actions.yaml b/Documentation/devicetree/bindings/arm/actions.yaml
> new file mode 100644
> index 000000000000..af9345a228b4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/actions.yaml
> @@ -0,0 +1,34 @@
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/arm/actions.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
404 for the schema. Where does one find an explanation?
> +
> +title: Actions Semi platforms device tree bindings
> +
> +maintainers:
> + - Andreas Färber <afaerber@suse.de>
Mani is now officially reviewer and the closest I have to a
co-maintainer. I suggest we add him here in some form. I assume this is
independent of MAINTAINERS patterns though, or will get_maintainers.pl
parse this, too?
> +
> +description: |
Does the | have any meaning, or a stray typo?
> + The Actions Semi S500 is a quad-core ARM Cortex-A9 SoC. The Actions Semi
> + S900 is a quad-core ARM Cortex-A53 SoC.
You forgot the S700 as another quad-core Cortex-A53 SoC.
Also, arm or Arm rather than ARM these days?
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - lemaker,guitar-bb-rev-b
> + - enum:
> + - lemaker,guitar
> + - allo,sparky
> + - cubietech,cubieboard6
> + - const: actions,s500
> + minItems: 2
> + maxItems: 3
> + additionalItems: false
Objection. You've managed to turn a perfectly human-comprehensible text
into a machine-parseable representation incomprehensible for humans.
First, there should remain some free-text explanation of the values
defined here. Are comments allowed after the value or indented maybe?
Alternatively we could have a per-vendor file à la vendor-prefixes.txt,
but that would seem inefficient.
Next, the above items construct is horrible. What about nested oneOf:
+ - items:
+ - oneOf:
+ - items:
+ - enum:
+ - lemaker,guitar-bb-rev-b
+ - const: lemaker,guitar
+ - items:
+ - enum:
+ - allo,sparky
+ - cubietech,cubieboard6
+ - const: actions,s500
This grouping is much clearer to me and hopefully to anyone adding
further base boards for the module.
We will have the same issue for the BPi-S64 module with S700 below.
> + - items:
> + - const: cubietech,cubieboard7
> + - const: actions,s700
> + - items:
> + - const: ucrobotics,bubblegum-96
> + - const: actions,s900
Please make the board compatible an enum, even if only one is listed
today. That makes it clearer where/how (and easier) to add new boards.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: Looking for architecture papers
From: Raz @ 2018-10-06 9:19 UTC (permalink / raw)
To: paubert; +Cc: linuxppc-dev
In-Reply-To: <20181004101640.t3o7v73fcipsjg3k@lt-gp.iram.es>
Hey
How does HVSC works ?
I looked in the code and LoPAR documentation. It looks like there is
vector called
system_call_pSeries ( at 0xc00 ) that is supposed to be called when we
invoke HVSC from kernel
mode.
Now, I wrote a NULL call HSVC and patched the exceptions-64s.S to
return RFID immediately.
This does not work.
Would you be so kind to explain how HVSC works ?
thank you
On Thu, Oct 4, 2018 at 1:16 PM Gabriel Paubert <paubert@iram.es> wrote:
>
> On Thu, Oct 04, 2018 at 10:41:13AM +0300, Raz wrote:
> > Frankly, the more I read the more perplexed I get. For example,
> > according to BOOK III-S, chapter 3,
> > the MSR bits are differ from the ones described in
> > arch/powerpc/include/asm/reg.h.
> > Bit zero, is LE, but in the book it is 64-bit mode.
>
> Just a problem of bit order definitions: IBM hardware definitions use
> big-endian bit ordering, where bit 0 is the most significant bit.
>
> >
> > Would someone be kind to explain what I do not understand?
> >
> > Thank you
>
> Gabriel
^ permalink raw reply
* Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
From: Bjorn Andersson @ 2018-10-06 7:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-fbdev, linux-iio, linux-pci, linux-remoteproc, linux-nvme,
platform-driver-x86, sparclinux, devel, linux-scsi, linux-nvdimm,
linux-rdma, qat-linux, amd-gfx, linux-input, linux-media,
linaro-mm-sig, dri-devel, ceph-devel, Greg Kroah-Hartman,
linux-usb, linux-wireless, linux-kernel, linux-crypto, netdev,
linux-fsdevel, linuxppc-dev, David S. Miller, linux-btrfs, viro
In-Reply-To: <20180912151134.436719-1-arnd@arndb.de>
On Wed 12 Sep 08:08 PDT 2018, Arnd Bergmann wrote:
[..]
> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> index a76b963a7e50..02aefb2b2d47 100644
> --- a/drivers/rpmsg/rpmsg_char.c
> +++ b/drivers/rpmsg/rpmsg_char.c
> @@ -285,7 +285,7 @@ static const struct file_operations rpmsg_eptdev_fops = {
> .write = rpmsg_eptdev_write,
> .poll = rpmsg_eptdev_poll,
> .unlocked_ioctl = rpmsg_eptdev_ioctl,
> - .compat_ioctl = rpmsg_eptdev_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
> static ssize_t name_show(struct device *dev, struct device_attribute *attr,
> @@ -446,7 +446,7 @@ static const struct file_operations rpmsg_ctrldev_fops = {
> .open = rpmsg_ctrldev_open,
> .release = rpmsg_ctrldev_release,
> .unlocked_ioctl = rpmsg_ctrldev_ioctl,
> - .compat_ioctl = rpmsg_ctrldev_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
For rpmsg part
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 33/36] dt-bindings: arm: Convert Tegra board/soc bindings to json-schema
From: Marcel Ziswiler @ 2018-10-05 22:19 UTC (permalink / raw)
To: robh@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Cc: mark.rutland@arm.com, trini@konsulko.com, kumar.gala@linaro.org,
glikely@secretlab.ca, arnd@arndb.de, linus.walleij@linaro.org,
pantelis.antoniou@konsulko.com, jonathanh@nvidia.com,
linux-tegra@vger.kernel.org, broonie@kernel.org,
thierry.reding@gmail.com, olof@lixom.net, geert@linux-m68k.org,
bjorn.andersson@linaro.org, frowand.list@gmail.com,
jic23@kernel.org
In-Reply-To: <20181005165848.3474-34-robh@kernel.org>
Hi Rob
On Fri, 2018-10-05 at 11:58 -0500, Rob Herring wrote:
> Convert Tegra SoC bindings to DT schema format using json-schema.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Jonathan Hunter <jonathanh@nvidia.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-tegra@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/arm/tegra.txt | 60 -------------
> .../devicetree/bindings/arm/tegra.yaml | 88
> +++++++++++++++++++
> 2 files changed, 88 insertions(+), 60 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/tegra.txt
> create mode 100644 Documentation/devicetree/bindings/arm/tegra.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/tegra.txt
> b/Documentation/devicetree/bindings/arm/tegra.txt
> deleted file mode 100644
> index 32f62bb7006d..000000000000
> --- a/Documentation/devicetree/bindings/arm/tegra.txt
> +++ /dev/null
> @@ -1,60 +0,0 @@
> -NVIDIA Tegra device tree bindings
> --------------------------------------------
> -
> -SoCs
> --------------------------------------------
> -
> -Each device tree must specify which Tegra SoC it uses, using one of
> the
> -following compatible values:
> -
> - nvidia,tegra20
> - nvidia,tegra30
> - nvidia,tegra114
> - nvidia,tegra124
> - nvidia,tegra132
> - nvidia,tegra210
> - nvidia,tegra186
> - nvidia,tegra194
> -
> -Boards
> --------------------------------------------
> -
> -Each device tree must specify which one or more of the following
> -board-specific compatible values:
> -
> - ad,medcom-wide
> - ad,plutux
> - ad,tamonten
> - ad,tec
> - compal,paz00
> - compulab,trimslice
> - nvidia,beaver
> - nvidia,cardhu
> - nvidia,cardhu-a02
> - nvidia,cardhu-a04
> - nvidia,dalmore
> - nvidia,harmony
> - nvidia,jetson-tk1
> - nvidia,norrin
> - nvidia,p2371-0000
> - nvidia,p2371-2180
> - nvidia,p2571
> - nvidia,p2771-0000
> - nvidia,p2972-0000
> - nvidia,roth
> - nvidia,seaboard
> - nvidia,tn7
> - nvidia,ventana
> - toradex,apalis_t30
> - toradex,apalis_t30-eval
> - toradex,apalis-tk1
> - toradex,apalis-tk1-eval
> - toradex,colibri_t20-512
> - toradex,colibri_t30
> - toradex,colibri_t30-eval-v3
> - toradex,iris
Are you aware that -next already features a few updating commits
thereof from around the beginning of September one of which even bears
your reviewed-by.
> -
> -Trusted Foundations
> --------------------------------------------
> -Tegra supports the Trusted Foundation secure monitor. See the
> -"tlm,trusted-foundations" binding's documentation for more details.
> diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml
> b/Documentation/devicetree/bindings/arm/tegra.yaml
> new file mode 100644
> index 000000000000..9cebcfaaad1e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/tegra.yaml
> @@ -0,0 +1,88 @@
> +# SPDX-License-Identifier: None
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/bindings/arm/tegra.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA Tegra device tree bindings
> +
> +maintainers:
> + - Marcel Ziswiler <marcel.ziswiler@toradex.com>
Wow, seems I got promoted to maintainer now. I guess that may make
sense at least for the Toradex based boards.
> + - Peter De Schrijver <pdeschrijver@nvidia.com>
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - compal,paz00
> + - compulab,trimslice
> + - nvidia,harmony
> + - nvidia,seaboard
> + - nvidia,ventana
> + - const: nvidia,tegra20
> + - items:
> + - enum:
> + - ad,medcom-wide
> + - ad,plutux
> + - ad,tec
> + - const: ad,tamonten
> + - const: nvidia,tegra20
> + - items:
> + - const: toradex,iris
> + - const: toradex,colibri_t20-512
> + - const: nvidia,tegra20
> + - items:
> + - enum:
> + - nvidia,beaver
> + - const: nvidia,tegra30
> + - items:
> + - enum:
> + - nvidia,cardhu-a02
> + - nvidia,cardhu-a04
> + - const: nvidia,cardhu
> + - const: nvidia,tegra30
> + - items:
> + - enum:
> + - toradex,apalis_t30-eval
> + - const: toradex,apalis_t30
> + - const: nvidia,tegra30
> + - items:
> + - enum:
> + - toradex,colibri_t30-eval-v3
> + - const: toradex,colibri_t30
> + - const: nvidia,tegra30
> + - items:
> + - enum:
> + - nvidia,dalmore
> + - nvidia,roth
> + - nvidia,tn7
> + - const: nvidia,tegra114
> + - items:
> + - enum:
> + - nvidia,jetson-tk1
> + - nvidia,venice2
> + - const: nvidia,tegra124
> + - items:
> + - const: toradex,apalis-tk1-eval
> + - const: toradex,apalis-tk1
> + - const: nvidia,tegra124
> + - items:
> + - enum:
> + - nvidia,norrin
> + - const: nvidia,tegra132
> + - const: nvidia,tegra124
> + - items:
> + - enum:
> + - nvidia,p2371-0000
> + - nvidia,p2371-2180
> + - nvidia,p2571
> + - const: nvidia,tegra210
> + - items:
> + - enum:
> + - nvidia,p2771-0000
> + - const: nvidia,tegra186
> + - items:
> + - enum:
> + - nvidia,p2972-0000
> + - const: nvidia,tegra194
Other than that I'm all in to move towards more structured bindings documentation.
Cheers
Marcel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox