* [PATCH 2/8] dt-bindings: serial: Add bindings for nvidia, tegra194-tcu
From: Mikko Perttunen @ 2018-05-08 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508114403.14499-1-mperttunen@nvidia.com>
Add bindings for the Tegra Combined UART device used to talk to the
UART console on Tegra194 systems.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
.../bindings/serial/nvidia,tegra194-tcu.txt | 35 ++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.txt
diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.txt b/Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.txt
new file mode 100644
index 000000000000..86763bc5d74f
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.txt
@@ -0,0 +1,35 @@
+NVIDIA Tegra Combined UART (TCU)
+
+The TCU is a system for sharing a hardware UART instance among multiple
+systems withing the Tegra SoC. It is implemented through a mailbox-
+based protocol where each "virtual UART" has a pair of mailboxes, one
+for transmitting and one for receiving, that is used to communicate
+with the hardware implementing the TCU.
+
+Required properties:
+- name : Should be tcu
+- compatible
+ Array of strings
+ One of:
+ - "nvidia,tegra194-tcu"
+- mbox-names:
+ "rx" - Mailbox for receiving data from hardware UART
+ "tx" - Mailbox for transmitting data to hardware UART
+- mboxes: Mailboxes corresponding to the mbox-names.
+
+This node is a mailbox consumer. See the following files for details of
+the mailbox subsystem, and the specifiers implemented by the relevant
+provider(s):
+
+- .../mailbox/mailbox.txt
+- .../mailbox/nvidia,tegra186-hsp.txt
+
+Example bindings:
+-----------------
+
+tcu: tcu {
+ compatible = "nvidia,tegra194-tcu";
+ mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_SM 0>,
+ <&hsp_aon TEGRA_HSP_MBOX_TYPE_SM 1>;
+ mbox-names = "rx", "tx";
+};
--
2.16.1
^ permalink raw reply related
* [PATCH 1/8] dt-bindings: tegra186-hsp: Add shared interrupts
From: Mikko Perttunen @ 2018-05-08 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508114403.14499-1-mperttunen@nvidia.com>
Non-doorbell interrupts are routed through "shared interrupts". These
interrupts can be mapped to various internal interrupt lines. Add
interrupt properties for shared interrupts to the tegra186-hsp device
tree bindings.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
index b99d25fc2f26..9edcdf82d719 100644
--- a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
+++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
@@ -21,6 +21,8 @@ Required properties:
Contains a list of names for the interrupts described by the interrupt
property. May contain the following entries, in any order:
- "doorbell"
+ - "sharedN", where 'N' is a number from zero up to the number of
+ external interrupts supported by the HSP instance minus one.
Users of this binding MUST look up entries in the interrupt property
by name, using this interrupt-names property to do so.
- interrupts
--
2.16.1
^ permalink raw reply related
* [PATCH 0/8] Tegra Combined UART driver
From: Mikko Perttunen @ 2018-05-08 11:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
on Tegra194, the primary console UART is the "Tegra Combined UART",
or TCU. This is a "virtual UART", where each consumer communicates
with a central implementation over mailboxes. The central
implementation then multiplexes the streams and arbitrates use of
a hardware serial port. This driver implements the consumer portion
to allow using the primary console.
The series is split into the following parts:
* patches 1 and 2 add the device tree bindings for mailbox and tcu
itself.
* patch 3 adds a blocking transmission option to the mailbox
framework.
* patches 4 and 5 add support for the "shared mailbox" primitive
to the Tegra HSP driver.
* patch 6 adds the TCU driver itself
* patches 7 and 8 do the necessary device tree changes.
The series has been tested on the Tegra194 P2972 board.
Thanks,
Mikko
Mikko Perttunen (8):
dt-bindings: tegra186-hsp: Add shared interrupts
dt-bindings: serial: Add bindings for nvidia,tegra194-tcu
mailbox: Add transmit done by blocking option
mailbox: tegra-hsp: Refactor in preparation of mailboxes
mailbox: tegra-hsp: Add support for shared mailboxes
serial: Add Tegra Combined UART driver
arm64: tegra: Add nodes for tcu on Tegra194
arm64: tegra: Mark tcu as primary serial port on Tegra194 P2888
.../bindings/mailbox/nvidia,tegra186-hsp.txt | 2 +
.../bindings/serial/nvidia,tegra194-tcu.txt | 35 +++
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 2 +-
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 34 ++-
drivers/mailbox/mailbox.c | 30 +-
drivers/mailbox/mailbox.h | 1 +
drivers/mailbox/tegra-hsp.c | 320 +++++++++++++++++----
drivers/tty/serial/Kconfig | 9 +
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/tegra-tcu.c | 302 +++++++++++++++++++
include/uapi/linux/serial_core.h | 3 +
11 files changed, 671 insertions(+), 68 deletions(-)
create mode 100644 Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.txt
create mode 100644 drivers/tty/serial/tegra-tcu.c
--
2.16.1
^ permalink raw reply
* [PATCH 1/2] arm64: signal: Report signal frame size to userspace via auxv
From: Dave Martin @ 2018-05-08 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508113043.elgvfz3dud2amcif@lakrids.cambridge.arm.com>
On Tue, May 08, 2018 at 12:30:44PM +0100, Mark Rutland wrote:
> On Tue, May 08, 2018 at 11:43:30AM +0100, Dave Martin wrote:
> > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> > index fac1c4d..771c7a8 100644
> > --- a/arch/arm64/include/asm/elf.h
> > +++ b/arch/arm64/include/asm/elf.h
> > @@ -24,6 +24,10 @@
> > #include <asm/ptrace.h>
> > #include <asm/user.h>
> >
> > +#ifndef __ASSEMBLY__
> > +#include <asm/processor.h> /* for get_minsigstksz(), used by ARCH_DLINFO */
> > +#endif
>
> This can live under the existing ifndef __ASSEMBLY__ block, where
> ARCH_DLINFO lives.
Can do. I don't usually like mixing #includes with the code unless absolutely necessary, but this looks like a pretty trivial case, with just some #defines before the #ifndef __ASSEMBLY__ block.
So I guess this can be moved harmlessly.
>
> [...]
>
> > +/*
> > + * Determine the stack space required for guaranteed signal devliery.
> > + * This function is used to populate AT_MINSIGSTKSZ at process startup.
> > + */
> > +int get_minsigstksz(void)
> > +{
> > + static __read_mostly atomic_t minsigstksz;
> > +
> > + int ret;
> > + struct rt_sigframe_user_layout user;
> > +
> > + ret = atomic_read(&minsigstksz);
> > + if (ret)
> > + return ret;
> > +
> > + init_user_layout(&user);
> > + ret = setup_sigframe_layout(&user, true);
> > +
> > + if (ret) {
> > + WARN_ON(1);
> > +
> > + ret = SIGSTKSZ;
> > + } else {
> > + ret = sigframe_size(&user) +
> > + round_up(sizeof(struct frame_record), 16) +
> > + 16; /* max alignment padding */
> > + }
> > +
> > + /*
> > + * The computed value (ret) is invariant, so its value can be
> > + * safely stored irrespective of whether some other racing
> > + * task got there first:
> > + */
> > + atomic_set(&minsigstksz, ret);
> > + return ret;
> > +}
>
> Can we set up minsigstksz at some initcall time? that way get_minstksz()
> can return minsigstksz with no conditionality at all.
I would have preferred to do that, but I wasn't sure where to put it.
Unless arch_initcall_sync() works for this, I don't know what to
suggest.
Cheers
---Dave
^ permalink raw reply
* [RESEND PATCH v2] bus: arm-cci: use asm unreachable
From: Stefan Agner @ 2018-05-08 11:32 UTC (permalink / raw)
To: linux-arm-kernel
Mixing asm and C code is not recommended in a naked function by
gcc and leads to an error when using clang:
drivers/bus/arm-cci.c:2107:2: error: non-ASM statement in naked
function is not supported
unreachable();
^
While the function is marked __naked it actually properly return
in asm. There is no need for the unreachable() call.
Suggested-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Nicolas Pitre <nico@linaro.org>
---
drivers/bus/arm-cci.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 443e4c3fd357..b8184a903583 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -371,8 +371,6 @@ asmlinkage void __naked cci_enable_port_for_self(void)
[sizeof_struct_cpu_port] "i" (sizeof(struct cpu_port)),
[sizeof_struct_ace_port] "i" (sizeof(struct cci_ace_port)),
[offsetof_port_phys] "i" (offsetof(struct cci_ace_port, phys)) );
-
- unreachable();
}
/**
--
2.17.0
^ permalink raw reply related
* [PATCH 1/2] arm64: signal: Report signal frame size to userspace via auxv
From: Mark Rutland @ 2018-05-08 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525776211-28169-2-git-send-email-Dave.Martin@arm.com>
On Tue, May 08, 2018 at 11:43:30AM +0100, Dave Martin wrote:
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index fac1c4d..771c7a8 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -24,6 +24,10 @@
> #include <asm/ptrace.h>
> #include <asm/user.h>
>
> +#ifndef __ASSEMBLY__
> +#include <asm/processor.h> /* for get_minsigstksz(), used by ARCH_DLINFO */
> +#endif
This can live under the existing ifndef __ASSEMBLY__ block, where
ARCH_DLINFO lives.
[...]
> +/*
> + * Determine the stack space required for guaranteed signal devliery.
> + * This function is used to populate AT_MINSIGSTKSZ at process startup.
> + */
> +int get_minsigstksz(void)
> +{
> + static __read_mostly atomic_t minsigstksz;
> +
> + int ret;
> + struct rt_sigframe_user_layout user;
> +
> + ret = atomic_read(&minsigstksz);
> + if (ret)
> + return ret;
> +
> + init_user_layout(&user);
> + ret = setup_sigframe_layout(&user, true);
> +
> + if (ret) {
> + WARN_ON(1);
> +
> + ret = SIGSTKSZ;
> + } else {
> + ret = sigframe_size(&user) +
> + round_up(sizeof(struct frame_record), 16) +
> + 16; /* max alignment padding */
> + }
> +
> + /*
> + * The computed value (ret) is invariant, so its value can be
> + * safely stored irrespective of whether some other racing
> + * task got there first:
> + */
> + atomic_set(&minsigstksz, ret);
> + return ret;
> +}
Can we set up minsigstksz at some initcall time? that way get_minstksz()
can return minsigstksz with no conditionality at all.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v5 13/14] KVM: arm64: Fold redundant exit code checks out of fixup_guest_exit()
From: Dave Martin @ 2018-05-08 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eddc101f-6f6c-a37b-ae48-e80a24f60815@arm.com>
On Tue, May 08, 2018 at 11:59:25AM +0100, Marc Zyngier wrote:
> On 04/05/18 17:05, Dave Martin wrote:
> > The entire tail of fixup_guest_exit() is contained in if statements
> > of the form if (x && *exit_code == ARM_EXCEPTION_TRAP). As a result,
> > we can check just once and bail out of the function early, allowing
> > the remaining if conditions to be simplified.
> >
> > The only awkward case is where *exit_code is changed to
> > ARM_EXCEPTION_EL1_SERROR in the case of an illegal GICv2 CPU
> > interface access: in that case, the GICv3 trap handling code is
> > skipped using a goto. This avoids pointlessly evaluating the
> > static branch check for the GICv3 case, even though we can't have
> > vgic_v2_cpuif_trap and vgic_v3_cpuif_trap true simultaneously
> > unless we have a GICv3 and GICv2 on the host: that sounds stupid,
> > but I haven't satisfied myself that it can't happen.
>
> Indeed, this cannot happen, unless we decided to trap access to the
> memory-mapped interface of a GICv3 implementation. We don't do that.
>
> But I guess the goto also serves a visual clue that the two cases are
> mutually exclusives. Small nit below though:
>
> >
> > No functional change.
> >
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > ---
> > arch/arm64/kvm/hyp/switch.c | 11 +++++++----
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> > index 39e9166..be09c52 100644
> > --- a/arch/arm64/kvm/hyp/switch.c
> > +++ b/arch/arm64/kvm/hyp/switch.c
> > @@ -385,11 +385,13 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> > * same PC once the SError has been injected, and replay the
> > * trapping instruction.
> > */
> > - if (*exit_code == ARM_EXCEPTION_TRAP && !__populate_fault_info(vcpu))
> > + if (*exit_code != ARM_EXCEPTION_TRAP)
> > + goto exit;
> > +
> > + if (!__populate_fault_info(vcpu))
> > return true;
> >
> > - if (static_branch_unlikely(&vgic_v2_cpuif_trap) &&
> > - *exit_code == ARM_EXCEPTION_TRAP) {
> > + if (static_branch_unlikely(&vgic_v2_cpuif_trap)) {
> > bool valid;
> >
> > valid = kvm_vcpu_trap_get_class(vcpu) == ESR_ELx_EC_DABT_LOW &&
> > @@ -414,12 +416,12 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> > if (!__skip_instr(vcpu))
> > *vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
> > *exit_code = ARM_EXCEPTION_EL1_SERROR;
> > + goto exit;
>
> This goto...
>
> > }
>
> ... should be placed here. If this was a data abort, it cannot be a
> system register trap, and the below conditions cannot possibly apply.
That sounds logically sensible, but to be clear, this would be a
semantic change to this function, right?
(i.e., it forces skipping of the GICv3 handling code in a case where
it previously wasn't forced -- at least not within this function. The
arguments about whether vgic_v2_cpuif_trap and vgic_v3_cpuif_trap can
ever be true simultaneously still apply.)
Cheers
---Dave
^ permalink raw reply
* [PATCH v5 10/14] KVM: arm64: Save host SVE context as appropriate
From: Dave Martin @ 2018-05-08 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0c616c43-3bff-1c93-0463-fae1c53c0e51@arm.com>
On Tue, May 08, 2018 at 11:38:05AM +0100, Marc Zyngier wrote:
> On 04/05/18 17:05, Dave Martin wrote:
> > This patch adds SVE context saving to the hyp FPSIMD context switch
> > path. This means that it is no longer necessary to save the host
> > SVE state in advance of entering the guest, when in use.
> >
> > In order to avoid adding pointless complexity to the code, VHE is
> > assumed if SVE is in use. VHE is an architectural prerequisite for
> > SVE, so there is no good reason to turn CONFIG_ARM64_VHE off in
> > kernels that support both SVE and KVM.
> >
> > Historically, software models exist that can expose the
> > architecturally invalid configuration of SVE without VHE, so if
> > this situation is detected this patch warns and refuses to create a
> > VM. Doing this check at VM creation time avoids race issues
> > between KVM and SVE initialisation.
> >
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
> > ---
> > arch/arm64/Kconfig | 7 +++++++
> > arch/arm64/kvm/fpsimd.c | 1 -
> > arch/arm64/kvm/hyp/switch.c | 21 +++++++++++++++++++--
> > virt/kvm/arm/arm.c | 18 ++++++++++++++++++
> > 4 files changed, 44 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index eb2cf49..b0d3820 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -1130,6 +1130,7 @@ endmenu
> > config ARM64_SVE
> > bool "ARM Scalable Vector Extension support"
> > default y
> > + depends on !KVM || ARM64_VHE
>
> In that case, should we consider making ARM64_VHE "default y" as well,
> as KVM is "default y" too?
Surely ARM64_VHE has always been default y?
1f364c8c48a0 ("arm64: VHE: Add support for running Linux in EL2 mode")
> Otherwise, I fear we end-up regressing existing configurations. Also,
> you still have to check for the configuration at run time, so I'm not
> immediately getting the point of this particular change.
We check for the configuration, but the penalty is severe (i.e., can't
create VMs) and it doesn't appear to make sense to put effort into
working around that: the user has an easy fix in the form of setting
ARM64_VHE=y.
Is there some value to supporting this configuration that I'm missing?
SVE and VHE are both default y.
[...]
> > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> > index 6cf499b..a7be7bf 100644
> > --- a/virt/kvm/arm/arm.c
> > +++ b/virt/kvm/arm/arm.c
> > @@ -16,6 +16,7 @@
> > * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
> > */
> >
> > +#include <linux/bug.h>
> > #include <linux/cpu_pm.h>
> > #include <linux/errno.h>
> > #include <linux/err.h>
> > @@ -41,6 +42,7 @@
> > #include <asm/mman.h>
> > #include <asm/tlbflush.h>
> > #include <asm/cacheflush.h>
> > +#include <asm/cpufeature.h>
> > #include <asm/virt.h>
> > #include <asm/kvm_arm.h>
> > #include <asm/kvm_asm.h>
> > @@ -120,6 +122,22 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > if (type)
> > return -EINVAL;
> >
> > + /*
> > + * VHE is a prerequisite for SVE in the Arm architecture, and
> > + * Kconfig ensures that if system_supports_sve() here then
> > + * CONFIG_ARM64_VHE is enabled, so if VHE support wasn't already
> > + * detected and enabled, the CPU is architecturally
> > + * noncompliant.
> > + *
> > + * Just in case this mismatch is seen, detect it, warn and give
> > + * up. Supporting this forbidden configuration in Hyp would be
> > + * pointless.
> > + */
> > + if (system_supports_sve() && !has_vhe()) {
> > + kvm_pr_unimpl("Cannot create VMs on SVE system without VHE. Broken cpu?");
> > + return -ENXIO;
> > + }
>
> You might as well fail the boot KVM initialization altogether, and not
> wait for a VM to be created.
I was concerned that the SVE and KVM initialisation might happen in
an unpredictable order.
KVM is initialised via module_init(), which I'm guessing is later than
cpufeatures (?) If so then yes, kvm_arch_init() would be a reasonable
place to do this.
> But I'm more concerned with the fact that we're now have a configuration
> that drops functionalities on the floor, one way or another.
Is this still a problem if that configuration is forbidden by Kconfig?
Can you describe a scenario in which the problem config (KVM=y, VHE=n,
SVE=y) would be wanted?
Cheers
---Dave
^ permalink raw reply
* [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions
From: Russell King - ARM Linux @ 2018-05-08 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152540727123.29650.13679359124038587629.stgit@devbox>
On Fri, May 04, 2018 at 01:14:31PM +0900, Masami Hiramatsu wrote:
> Hi,
>
> This is the 3rd version of bugfix series for kprobes on arm.
> This series fixes 4 different issues which I found.
>
> - Fix to use smp_processor_id() after disabling preemption.
> - Prohibit probing on optimized_callback() for avoiding
> recursive probe.
> - Prohibit kprobes on do_undefinstr() by same reason.
> - Prohibit kprobes on get_user() by same reason.
>
> >From v2, I included another 2 bugfixes (1/4 and 2/4)
> which are not merged yet, and added "Cc: stable at vger.kernel.org",
> since there are obvious bugs.
Please submit them to the patch system, thanks.
>
> Thanks,
>
> ---
>
> Masami Hiramatsu (4):
> arm: kprobes: Fix to use get_kprobe_ctlblk after irq-disabed
> arm: kprobes: Prohibit probing on optimized_callback
> arm: kprobes: Prohibit kprobes on do_undefinstr
> arm: kprobes: Prohibit kprobes on get_user functions
>
>
> arch/arm/include/asm/assembler.h | 10 ++++++++++
> arch/arm/kernel/traps.c | 5 ++++-
> arch/arm/lib/getuser.S | 10 ++++++++++
> arch/arm/probes/kprobes/opt-arm.c | 4 +++-
> 4 files changed, 27 insertions(+), 2 deletions(-)
>
> --
> Masami Hiramatsu (Linaro) <mhiramat@kernel.org>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices
From: Marcel Holtmann @ 2018-05-08 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525767775.18877.22.camel@mtkswgap22>
Hi Sean,
>>>>> +
>>>>> +static int mtk_wmt_cmd_sync(struct hci_uart *hu, u8 opcode, u8 flag, u16 plen,
>>>>> + const void *param)
>>>>> +{
>>>>> + struct mtk_bt_dev *btdev = hu->priv;
>>>>> + struct hci_command_hdr *hhdr;
>>>>> + struct hci_acl_hdr *ahdr;
>>>>> + struct mtk_wmt_hdr *whdr;
>>>>> + struct sk_buff *skb;
>>>>> + int ret = 0;
>>>>> +
>>>>> + init_completion(&btdev->wmt_cmd);
>>>>> +
>>>>> + skb = bt_skb_alloc(plen + MTK_WMT_CMD_SIZE, GFP_KERNEL);
>>>>> + if (!skb)
>>>>> + return -ENOMEM;
>>>>> +
>>>>> + /*
>>>>> + * WMT data is carried in either ACL or HCI format with op code as
>>>>> + * 0xfc6f and followed by a WMT header and its actual payload.
>>>>> + */
>>>>
>>>> Please use net subsystem comment style.
>>>>
>>>>> + switch (opcode) {
>>>>> + case MTK_WMT_PATCH_DWNLD:
>>>>> + ahdr = skb_put(skb, HCI_ACL_HDR_SIZE);
>>>>> + ahdr->handle = cpu_to_le16(0xfc6f);
>>>>> + ahdr->dlen = cpu_to_le16(plen + MTK_WMT_HDR_SIZE);
>>>>> + break;
>>>>> + default:
>>>>> + hhdr = skb_put(skb, HCI_COMMAND_HDR_SIZE);
>>>>> + hhdr->opcode = cpu_to_le16(0xfc6f);
>>>>> + hhdr->plen = plen + MTK_WMT_HDR_SIZE;
>>>>> + break;
>>>>> + }
>>>>> +
>>>>> + hci_skb_pkt_type(skb) = opcode == MTK_WMT_PATCH_DWNLD ?
>>>>> + HCI_ACLDATA_PKT : HCI_COMMAND_PKT;
>>>>
>>>> Why not move that into the switch statement above.
>>>>
>>>>> +
>>>>> + /* Start to build a WMT header and its actual payload. */
>>>>> + whdr = skb_put(skb, MTK_WMT_HDR_SIZE);
>>>>> + whdr->dir = 1;
>>>>> + whdr->op = opcode;
>>>>> + whdr->dlen = cpu_to_le16(plen + 1);
>>>>> + whdr->flag = flag;
>>>>> + skb_put_data(skb, param, plen);
>>>>> +
>>>>> + mtk_enqueue(hu, skb);
>>>>> + hci_uart_tx_wakeup(hu);
>>>>> +
>>>>> + /*
>>>>> + * Waiting a WMT event response, while we must take care in case of
>>>>> + * failures for the wait.
>>>>> + */
>>>>> + ret = wait_for_completion_interruptible_timeout(&btdev->wmt_cmd, HZ);
>>>>> +
>>>>> + return ret > 0 ? 0 : ret < 0 ? ret : -ETIMEDOUT;
>>>>> +}
>>>>
>>>> All in all I am not convinced that this is super clean. I get that we need something special for having this in the ACL data packets, but for the standard HCI command I prefer that __hci_cmd_sync is used. I addition, it seems that patch download is the only special case and that happens before at the setup stage. So we could make things special for that. I need to understand this a bit better. Can I get a btmon -w trace.log file from the whole init procedure.
>>>>
>>>
>>> While i was trying to rewrite the driver based on btuart.c. you posted
>>> on RFC, I used __hci_cmd_sync_ev to replace such kinds of SoC specific
>>> hci command sending which I've done previously with mtk_wmt_cmd_sync.
>>>
>>> However, eventually, I got a cmd_timer timeout whose message printed
>>> on console as "Bluetooth: hci0: command 0xfc6f tx timeout".
>>>
>>> The mtk soc specific cmd/event I posted below, I dumped directly in
>>> driver, always uses cmd as opcode 0xfc6f, and its event id as 0xe4.
>>>
>>> It appears to the event id is not standard and thus it cannot cancel the
>>> cmd timer when the special hci event is being handled. This way can we
>>> can still use __hci_cmd_sync api ?
>>>
>>> [ 4.896200] hci tx: 00000000: 01 6f fc 05 01 07 01 00 04
>>> [ 4.904671] hci rx: 00000000: e4 05 02 07 01 00
>>> 00
>>> [ 4.912859] Bluetooth: hci0 event 0xe4
>>>
>>>
>>> buildroot login: [ 6.914509] Bluetooth: hci0: command 0xfc6f tx
>>> timeout
>>> [ 6.919831] hci tx: 00000000: 01 6f fc 06 01 06 02 00 00
>>> 01 .o........
>>> [ 7.006631] hci rx: 00000000: e4 05 02 06 01 00
>>> 00 .......
>>> [ 7.014821] Bluetooth: hci0 event 0xe4
>>
>> can you just start btmon before loading the module / driver? It makes it a lot easier since it will actually decode the basics for us. If there is a bug within __hci_cmd_sync_ev, then we are going to fix it.
>>
>
> I'm happy to do with btmon. just the environment with buildroot the BT
> running on seems there's a missing support for btmon. I can start to use
> btmon once I change the environment to Debian.
>
>> So all the MTK vendor commands respond with a vendor event? Or are there some that do the standard command status/complete handling?
>>
>
> yes, mtk controller after mt7622 (included), its MTK vendors command
> (opcode 0xfc6f) always respond with a vendor event id 0xe4. And they
> don't do any standard status/complete handling.
then we need to figure out where the __hci_cmd_sync_ev causes a problem. Since normally that should just work for you.
> BTW, mtk controller before mt7622, such as mt7623, its MTK vendor
> command always go with completely specific format, not with hci format.
What does that mean? Do you have an example?
Regards
Marcel
^ permalink raw reply
* [PATCH v2 11/17] kvm: arm64: Configure VTCR per VM
From: Suzuki K Poulose @ 2018-05-08 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1175bc06-14b1-63e4-7b99-55c22db1c451@arm.com>
On 03/05/18 15:39, James Morse wrote:
> Hi Suzuki,
>
> On 27/03/18 14:15, Suzuki K Poulose wrote:
>> We set VTCR_EL2 very early during the stage2 init and don't
>> touch it ever. This is fine as we had a fixed IPA size. This
>> patch changes the behavior to set the VTCR for a given VM,
>> depending on its stage2 table. The common configuration for
>> VTCR is still performed during the early init as we have to
>> retain the hardware access flag update bits (VTCR_EL2_HA)
>> per CPU (as they are only set for the CPUs which are capabile).
>> The bits defining the number of levels in the page table (SL0)
>> and and the size of the Input address to the translation (T0SZ)
>> are programmed for each VM upon entry to the guest.
>
>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 596f8e4..9f3c8b8 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -392,10 +392,12 @@ int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
>>
>> static inline void __cpu_init_stage2(void)
>> {
>> - u32 parange = kvm_call_hyp(__init_stage2_translation);
>> + u32 ps;
>>
>> - WARN_ONCE(parange < 40,
>> - "PARange is %d bits, unsupported configuration!", parange);
>> + kvm_call_hyp(__init_stage2_translation);
>> + ps = id_aa64mmfr0_parange_to_phys_shift(read_sysreg(id_aa64mmfr0_el1));
>
> Doesn't id_aa64mmfr0_parange_to_phys_shift() expect you do to the mask and shift
> for it? This will always hit the default case.
Good catch ! The error case was not hit on the system I tested, as it was
indeed having 48bit PA. I should have done more testing with Juno where it
is 40bit PA (which doesn't really allow different phys-shift ranges).
I will change the helper to extract the parange and the convert it.
Also, rename it to :
id_aa64mmfr0_phys_shift()
Cheers
Suzuki
>
>
>> + WARN_ONCE(ps < 40,
>> + "PARange is %d bits, unsupported configuration!", ps);
>> }
>
>
>
> Thanks,
>
> James
>
^ permalink raw reply
* [PATCH v3 2/3] can: simplify LED trigger handling
From: Marc Kleine-Budde @ 2018-05-08 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508100543.12559-3-u.kleine-koenig@pengutronix.de>
On 05/08/2018 12:05 PM, Uwe Kleine-K?nig wrote:
> The new function led_trigger_register_format allows one to simplify LED
> trigger handling considerably.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180508/dd8e18c4/attachment.sig>
^ permalink raw reply
* [PATCH v5 14/14] KVM: arm64: Invoke FPSIMD context switch trap from C
From: Marc Zyngier @ 2018-05-08 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525449935-31424-15-git-send-email-Dave.Martin@arm.com>
On 04/05/18 17:05, Dave Martin wrote:
> The conversion of the FPSIMD context switch trap code to C has added
> some overhead to calling it, due to the need to save registers that
> the procedure call standard defines as caller-saved.
>
> So, perhaps it is no longer worth invoking this trap handler quite
> so early.
>
> Instead, we can invoke it from fixup_guest_exit(), with little
> likelihood of increasing the overhead much further.
>
> As a convenience, this patch gives __hyp_switch_fpsimd() the same
> return semantics fixup_guest_exit(). For now there is no
> possibility of a spurious FPSIMD trap, so the function always
> returns true, but this allows it to be tail-called with a single
> return statement.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] tty: pl011: Avoid spuriously stuck-off interrupts
From: Russell King - ARM Linux @ 2018-05-08 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1524823545-11309-2-git-send-email-Dave.Martin@arm.com>
On Fri, Apr 27, 2018 at 11:05:45AM +0100, Dave Martin wrote:
> Commit 9b96fbacda34 ("serial: PL011: clear pending interrupts")
> clears the RX and receive timeout interrupts on pl011 startup, to
> avoid a screaming-interrupt scenario that can occur when the
> firmware or bootloader leaves these interrupts asserted.
>
> This has been noted as an issue when running Linux on qemu [1].
>
> Unfortunately, the above fix seems to lead to potential
> misbehaviour if the RX FIFO interrupt is asserted _non_ spuriously
> on driver startup, if the RX FIFO is also already full to the
> trigger level.
>
> Clearing the RX FIFO interrupt does not change the FIFO fill level.
> In this scenario, because the interrupt is now clear and because
> the FIFO is already full to the trigger level, no new assertion of
> the RX FIFO interrupt can occur unless the FIFO is drained back
> below the trigger level. This never occurs because the pl011
> driver is waiting for an RX FIFO interrupt to tell it that there is
> something to read, and does not read the FIFO at all until that
> interrupt occurs.
>
> Thus, simply clearing "spurious" interrupts on startup may be
> misguided, since there is no way to be sure that the interrupts are
> truly spurious, and things can go wrong if they are not.
>
> This patch instead clears the interrupt condition by draining the
> RX FIFO during UART startup, after clearing any potentially
> spurious interrupt. This should ensure that an interrupt will
> definitely be asserted if the RX FIFO subsequently becomes
> sufficiently full.
>
> The drain is done at the point of enabling interrupts only. This
> means that it will occur any time the UART is newly opened through
> the tty layer. It will not apply to polled-mode use of the UART by
> kgdboc: since that scenario cannot use interrupts by design, this
> should not matter. kgdboc will interact badly with "normal" use of
> the UART in any case: this patch makes no attempt to paper over
> such issues.
>
> This patch does not attempt to address the case where the RX FIFO
> fills faster than it can be drained: that is a pathological
> hardware design problem that is beyond the scope of the driver to
> work around.
>
> [1] [Qemu-devel] [Qemu-arm] [PATCH] pl011: do not put into fifo
> before enabled the interruption
> https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg06446.html
>
> Reported-by: Wei Xu <xuwei5@hisilicon.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Peter Maydell <peter.maydell@linaro.org>
> Fixes: 9b96fbacda34 ("serial: PL011: clear pending interrupts")
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Tested-by: Andrew Jones <drjones@redhat.com>
> Reviewed-by: Andrew Jones <drjones@redhat.com>
> ---
> drivers/tty/serial/amba-pl011.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 4b40a5b..a6ccb85 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -1731,6 +1731,16 @@ static void pl011_enable_interrupts(struct uart_amba_port *uap)
>
> /* Clear out any spuriously appearing RX interrupts */
> pl011_write(UART011_RTIS | UART011_RXIS, uap, REG_ICR);
> +
> + /*
> + * RXIS is asserted only when the RX FIFO transitions from below
> + * to above the trigger threshold. If the RX FIFO is already
> + * full to the threshold this can't happen and RXIS will now be
> + * stuck off. Drain the RX FIFO explicitly to fix this:
> + */
> + while (!(pl011_read(uap, REG_FR) & UART01x_FR_RXFE))
> + pl011_read(uap, REG_DR);
You probably ought to limit this in case of a stuck receive not empty
case, maybe to (eg) twice the depth of the FIFO?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v5 13/14] KVM: arm64: Fold redundant exit code checks out of fixup_guest_exit()
From: Marc Zyngier @ 2018-05-08 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525449935-31424-14-git-send-email-Dave.Martin@arm.com>
On 04/05/18 17:05, Dave Martin wrote:
> The entire tail of fixup_guest_exit() is contained in if statements
> of the form if (x && *exit_code == ARM_EXCEPTION_TRAP). As a result,
> we can check just once and bail out of the function early, allowing
> the remaining if conditions to be simplified.
>
> The only awkward case is where *exit_code is changed to
> ARM_EXCEPTION_EL1_SERROR in the case of an illegal GICv2 CPU
> interface access: in that case, the GICv3 trap handling code is
> skipped using a goto. This avoids pointlessly evaluating the
> static branch check for the GICv3 case, even though we can't have
> vgic_v2_cpuif_trap and vgic_v3_cpuif_trap true simultaneously
> unless we have a GICv3 and GICv2 on the host: that sounds stupid,
> but I haven't satisfied myself that it can't happen.
Indeed, this cannot happen, unless we decided to trap access to the
memory-mapped interface of a GICv3 implementation. We don't do that.
But I guess the goto also serves a visual clue that the two cases are
mutually exclusives. Small nit below though:
>
> No functional change.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> ---
> arch/arm64/kvm/hyp/switch.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 39e9166..be09c52 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -385,11 +385,13 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> * same PC once the SError has been injected, and replay the
> * trapping instruction.
> */
> - if (*exit_code == ARM_EXCEPTION_TRAP && !__populate_fault_info(vcpu))
> + if (*exit_code != ARM_EXCEPTION_TRAP)
> + goto exit;
> +
> + if (!__populate_fault_info(vcpu))
> return true;
>
> - if (static_branch_unlikely(&vgic_v2_cpuif_trap) &&
> - *exit_code == ARM_EXCEPTION_TRAP) {
> + if (static_branch_unlikely(&vgic_v2_cpuif_trap)) {
> bool valid;
>
> valid = kvm_vcpu_trap_get_class(vcpu) == ESR_ELx_EC_DABT_LOW &&
> @@ -414,12 +416,12 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> if (!__skip_instr(vcpu))
> *vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
> *exit_code = ARM_EXCEPTION_EL1_SERROR;
> + goto exit;
This goto...
> }
... should be placed here. If this was a data abort, it cannot be a
system register trap, and the below conditions cannot possibly apply.
> }
> }
>
> if (static_branch_unlikely(&vgic_v3_cpuif_trap) &&
> - *exit_code == ARM_EXCEPTION_TRAP &&
> (kvm_vcpu_trap_get_class(vcpu) == ESR_ELx_EC_SYS64 ||
> kvm_vcpu_trap_get_class(vcpu) == ESR_ELx_EC_CP15_32)) {
> int ret = __vgic_v3_perform_cpuif_access(vcpu);
> @@ -428,6 +430,7 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> return true;
> }
>
> +exit:
> /* Return to the host kernel and handle the exit */
> return false;
> }
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 00/13] drm/kms/mode: using helper func drm_display_mode_to/from_videomode for calculating timing parameters
From: Satendra Singh Thakur @ 2018-05-08 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507134602.GH12521@phenom.ffwll.local>
On Thu, May 07, 2018 at 15:46:02 +0200, Daniel Vetter wrote:
> On Thu, May 03, 2018 at 01:53:55PM +0530, Satendra Singh Thakur wrote:
> > 1.There is a function in drm-core to calculate display timing parameters:
> > horizontal front porch, back porch, sync length,
> > vertical front porch, back porch, sync length and
> > clock in Hz.
> > However, some drivers are still calculating these parameters themselves.
> > Therefore, there is a duplication of the code.
> > This patch series replaces this redundant code with the function
> > drm_display_mode_to_videomode.
> > This removes nearly 100 redundant lines from the related drivers.
> > 2.For some drivers (sun4i) the reverse helper
> > drm_display_mode_from_videomode is used.
> > 3.For some drivers it replaces arithmatic operators (*, /) with shifting
> > operators (>>, <<).
> > 4.For some drivers DRM_MODE_FLAG_* are replaced with DISPLAY_FLAGS_* flags.
> > 5.These changes apply to following crtc and encoder drivers:
> > atmel-hlcdc
> > bridge-tc358767
> > exynos-dsi
> > fsl-dcu
> > gma500-mdfld_dsi_dpi
> > hisilicon-kirin_dsi, ade
> > meson-encoder
> > pl111-display
> > sun4i-tv
> > ti lcdc
> > tegra dc
> > mediatek dpi dsi
> > bridge-adv7533
>
> The drm_mode_to_videomode helper is meant for interop between drm and v4l,
> which have different internal structures to represent modes.
>
> For drivers that only use drm I think the better option would be to add
> these fields to struct drm_display_mode as another set of crtc_* values
> (the computed values are stored in crtc_ prefixed members). And compute
> front/back porch in drm_mode_set_crtcinfo.
>
> Then we can use these new drm_display_mode->crtc_h|vfront|back_porch
> fields in all the drivers you're changing. This way you avoid having to
> change all the drm drivers to use v4l #defines.
>
> Thanks,
> Daniel
Hi Daniel,
Thanks for the comments.
I will look into it.
Thanks
-Satendra
^ permalink raw reply
* [PATCH v7 05/11] ARM: smp: Add initialization of CNTVOFF
From: Russell King - ARM Linux @ 2018-05-08 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180420211022.11759-6-mylene.josserand@bootlin.com>
On Fri, Apr 20, 2018 at 11:10:16PM +0200, Myl?ne Josserand wrote:
> The CNTVOFF register from arch timer is uninitialized.
> It should be done by the bootloader but it is currently not the case,
> even for boot CPU because this SoC is booting in secure mode.
> It leads to an random offset value meaning that each CPU will have a
> different time, which isn't working very well.
>
> Add assembly code used for boot CPU and secondary CPU cores to make
> sure that the CNTVOFF register is initialized. Because this code can
> be used by different platforms, add this assembly file in ARM's common
> folder.
>
> Signed-off-by: Myl?ne Josserand <mylene.josserand@bootlin.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> arch/arm/common/Makefile | 1 +
> arch/arm/common/secure_cntvoff.S | 31 +++++++++++++++++++++++++++++++
> arch/arm/include/asm/secure_cntvoff.h | 8 ++++++++
> 3 files changed, 40 insertions(+)
> create mode 100644 arch/arm/common/secure_cntvoff.S
> create mode 100644 arch/arm/include/asm/secure_cntvoff.h
>
> diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
> index 70b4a14ed993..1e9f7af8f70f 100644
> --- a/arch/arm/common/Makefile
> +++ b/arch/arm/common/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_DMABOUNCE) += dmabounce.o
> obj-$(CONFIG_SHARP_LOCOMO) += locomo.o
> obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
> obj-$(CONFIG_SHARP_SCOOP) += scoop.o
> +obj-$(CONFIG_SMP) += secure_cntvoff.o
> obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
> obj-$(CONFIG_MCPM) += mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock.o
> CFLAGS_REMOVE_mcpm_entry.o = -pg
> diff --git a/arch/arm/common/secure_cntvoff.S b/arch/arm/common/secure_cntvoff.S
> new file mode 100644
> index 000000000000..68a4a8344319
> --- /dev/null
> +++ b/arch/arm/common/secure_cntvoff.S
> @@ -0,0 +1,31 @@
> +/* SPDX-License-Identifier: GPL-2.0
For assembly files, the SPDX specifier is of this format:
/* SPDX-License-Identifier: <SPDX License Expression> */
Please see Documentation/process/license-rules.rst for more
information, and fix your specifier to conform to the requirements.
Thanks.
> + *
> + * Copyright (C) 2014 Renesas Electronics Corporation
> + *
> + * Initialization of CNTVOFF register from secure mode
> + *
> + */
> +
> +#include <linux/linkage.h>
> +#include <asm/assembler.h>
> +
> +ENTRY(secure_cntvoff_init)
> + .arch armv7-a
> + /*
> + * CNTVOFF has to be initialized either from non-secure Hypervisor
> + * mode or secure Monitor mode with SCR.NS==1. If TrustZone is enabled
> + * then it should be handled by the secure code
This should also state that this code must not be executed if
virtualisation extensions are not present (which should be obvious)
as the mcrr instruction becomes unpredictable in that case.
> + */
> + cps #MON_MODE
> + mrc p15, 0, r1, c1, c1, 0 /* Get Secure Config */
> + orr r0, r1, #1
> + mcr p15, 0, r0, c1, c1, 0 /* Set Non Secure bit */
> + isb
> + mov r0, #0
> + mcrr p15, 4, r0, r0, c14 /* CNTVOFF = 0 */
> + isb
> + mcr p15, 0, r1, c1, c1, 0 /* Set Secure bit */
> + isb
> + cps #SVC_MODE
> + ret lr
> +ENDPROC(secure_cntvoff_init)
> diff --git a/arch/arm/include/asm/secure_cntvoff.h b/arch/arm/include/asm/secure_cntvoff.h
> new file mode 100644
> index 000000000000..1f93aee1f630
> --- /dev/null
> +++ b/arch/arm/include/asm/secure_cntvoff.h
> @@ -0,0 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
This one conforms.
> +
> +#ifndef __ASMARM_ARCH_CNTVOFF_H
> +#define __ASMARM_ARCH_CNTVOFF_H
> +
> +extern void secure_cntvoff_init(void);
> +
> +#endif
> --
> 2.11.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v3 3/3] tty: implement led triggers
From: Uwe Kleine-König @ 2018-05-08 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508100851.GY2285@localhost>
On Tue, May 08, 2018 at 12:08:51PM +0200, Johan Hovold wrote:
> On Tue, May 08, 2018 at 12:05:43PM +0200, Uwe Kleine-K?nig wrote:
> > The rx trigger fires when data is pushed to the ldisc by the driver. This
> > is a bit later than the actual receiving of data but has the nice benefit
> > that it doesn't need adaption for each driver and isn't in the hot path.
> >
> > Similarly the tx trigger fires when data was copied from userspace and is
> > given to the ldisc.
> >
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > ---
> > arch/arm/boot/dts/imx25-logitech-baby.dts | 192 ++++++++++++++++++++++
>
> Looks like you included more than intended in this patch.
Right, this doesn't belong here. Feel free to assume I didn't include it
in the patch and comment the rest :-)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v5 12/14] KVM: arm64: Remove redundant *exit_code changes in fpsimd_guest_exit()
From: Marc Zyngier @ 2018-05-08 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525449935-31424-13-git-send-email-Dave.Martin@arm.com>
On 04/05/18 17:05, Dave Martin wrote:
> In fixup_guest_exit(), there are a couple of cases where after
> checking what the exit code was, we assign it explicitly with the
> value it already had.
>
> Assuming this is not indicative of a bug, these assignments are not
> needed.
>
> This patch removes the redundant assignments simplifies some if-
> nesting that becomes trivial as a result.
>
> No functional change.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 3/3] dma-debug: unexport dma_debug_resize_entries and debug_dma_dump_mappings
From: Christoph Hellwig @ 2018-05-08 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bb5bb25f-24da-9729-a39b-3b88c65ef628@arm.com>
On Tue, May 08, 2018 at 11:05:20AM +0100, Robin Murphy wrote:
> On 24/04/18 15:02, Christoph Hellwig wrote:
>> Only used by the AMD GART driver, which must be built in.
>
> FWIW debug_dma_dump_mappings() is also called by the Intel VT-d driver, but
> the same reasoning still applies.
I'll update the changelog.
> This does rather beg the question of
> whether it's right to have bits of low-level dma-debug internals *only*
> called by a couple of IOMMU drivers, but that can wait for another day.
My gut feeling is that it is wrong, but I didn't have time to look into
the details and history of how this happened.
^ permalink raw reply
* [PATCH 2/2] arm64/sve: signal: Include SVE when computing AT_MINSIGSTKSZ
From: Dave Martin @ 2018-05-08 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525776211-28169-1-git-send-email-Dave.Martin@arm.com>
The SVE context block in the signal frame needs to be considered
too when computing the maximum possible signal frame size.
Because the size of this block depends on the vector length, this
patch computes the size based not on the thread's current vector
length but instead on the maximum possible vector length: this
determines the maximum size of SVE context block that can be
observed in any signal frame for the lifetime of the process.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Alex Benn?e <alex.bennee@linaro.org>
---
arch/arm64/kernel/signal.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index a4f1edf..3427c70 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -599,8 +599,18 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
if (system_supports_sve()) {
unsigned int vq = 0;
- if (test_thread_flag(TIF_SVE))
- vq = sve_vq_from_vl(current->thread.sve_vl);
+ if (add_all || test_thread_flag(TIF_SVE)) {
+ int vl = sve_max_vl;
+
+ if (!add_all)
+ vl = current->thread.sve_vl;
+
+ /* Fail safe if something wasn't initialised */
+ if (WARN_ON(!sve_vl_valid(vl)))
+ vl = SVE_VL_MIN;
+
+ vq = sve_vq_from_vl(vl);
+ }
err = sigframe_alloc(user, &user->sve_offset,
SVE_SIG_CONTEXT_SIZE(vq));
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] arm64: signal: Report signal frame size to userspace via auxv
From: Dave Martin @ 2018-05-08 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525776211-28169-1-git-send-email-Dave.Martin@arm.com>
Stateful CPU architecture extensions may require the signal frame
to grow to a size that exceeds the arch's MINSIGSTKSZ #define.
However, changing this #define is an ABI break.
To allow userspace the option of determining the signal frame size
in a more forwards-compatible way, this patch adds a new auxv entry
tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame
size that the process can observe during its lifetime.
If AT_MINSIGSTKSZ is absent from the aux vector, the caller can
assume that the MINSIGSTKSZ #define is sufficient. This allows for
a consistent interface with older kernels that do not provide
AT_MINSIGSTKSZ.
The idea is that libc could expose this via sysconf() or some
similar mechanism.
There is deliberately no AT_SIGSTKSZ. The kernel knows nothing
about userspace's own stack overheads and should not pretend to
know.
For arm64:
The primary motivation for this interface is the Scalable Vector
Extension, which can require at least 4KB or so of extra space
in the signal frame for the largest hardware implementations.
To determine the correct value, a "Christmas tree" mode (via the
add_all argument) is added to setup_sigframe_layout(), to simulate
addition of all possible records to the signal frame at maximum
possible size.
If this procedure goes wrong somehow, resulting in a stupidly large
frame layout and hence failure of sigframe_alloc() to allocate a
record to the frame, then this is indicative of a kernel bug: the
kernel's internal SIGFRAME_MAXSZ is supposed to sanity-check
against generting frames that we consider _impossibly_ large. In
this case, SIGSTKSZ is returned as a "reasonable guess that is at
least bigger than MINSIGSTKSZ" and we WARN().
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
Changes since v5:
* Cache the value computed for AT_MINSIGSTKSZ. This is invariant post-
boot, so recomputing it on every exec is pointless effort.
---
arch/arm64/include/asm/elf.h | 5 ++++
arch/arm64/include/asm/processor.h | 3 ++
arch/arm64/include/uapi/asm/auxvec.h | 3 +-
arch/arm64/kernel/signal.c | 54 ++++++++++++++++++++++++++++++++----
4 files changed, 59 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index fac1c4d..771c7a8 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -24,6 +24,10 @@
#include <asm/ptrace.h>
#include <asm/user.h>
+#ifndef __ASSEMBLY__
+#include <asm/processor.h> /* for get_minsigstksz(), used by ARCH_DLINFO */
+#endif
+
/*
* AArch64 static relocation types.
*/
@@ -148,6 +152,7 @@ typedef struct user_fpsimd_state elf_fpregset_t;
do { \
NEW_AUX_ENT(AT_SYSINFO_EHDR, \
(elf_addr_t)current->mm->context.vdso); \
+ NEW_AUX_ENT(AT_MINSIGSTKSZ, get_minsigstksz()); \
} while (0)
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 7675989..eee058f 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -244,6 +244,9 @@ void cpu_enable_pan(const struct arm64_cpu_capabilities *__unused);
void cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused);
void cpu_clear_disr(const struct arm64_cpu_capabilities *__unused);
+/* User signal frame size discovery: */
+int get_minsigstksz(void);
+
/* Userspace interface for PR_SVE_{SET,GET}_VL prctl()s: */
#define SVE_SET_VL(arg) sve_set_current_vl(arg)
#define SVE_GET_VL() sve_get_current_vl()
diff --git a/arch/arm64/include/uapi/asm/auxvec.h b/arch/arm64/include/uapi/asm/auxvec.h
index ec0a86d..a35797e 100644
--- a/arch/arm64/include/uapi/asm/auxvec.h
+++ b/arch/arm64/include/uapi/asm/auxvec.h
@@ -19,7 +19,8 @@
/* vDSO location */
#define AT_SYSINFO_EHDR 33
+#define AT_MINSIGSTKSZ 34 /* stack needed for signal delivery */
-#define AT_VECTOR_SIZE_ARCH 1 /* entries in ARCH_DLINFO */
+#define AT_VECTOR_SIZE_ARCH 2 /* entries in ARCH_DLINFO */
#endif
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 154b7d3..a4f1edf 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -17,6 +17,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/atomic.h>
#include <linux/compat.h>
#include <linux/errno.h>
#include <linux/kernel.h>
@@ -570,8 +571,15 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
return 0;
}
-/* Determine the layout of optional records in the signal frame */
-static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
+/*
+ * Determine the layout of optional records in the signal frame
+ *
+ * add_all: if true, lays out the biggest possible signal frame for
+ * this task; otherwise, generates a layout for the current state
+ * of the task.
+ */
+static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
+ bool add_all)
{
int err;
@@ -581,7 +589,7 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
return err;
/* fault information, if valid */
- if (current->thread.fault_code) {
+ if (add_all || current->thread.fault_code) {
err = sigframe_alloc(user, &user->esr_offset,
sizeof(struct esr_context));
if (err)
@@ -603,7 +611,6 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
return sigframe_alloc_end(user);
}
-
static int setup_sigframe(struct rt_sigframe_user_layout *user,
struct pt_regs *regs, sigset_t *set)
{
@@ -701,7 +708,7 @@ static int get_sigframe(struct rt_sigframe_user_layout *user,
int err;
init_user_layout(user);
- err = setup_sigframe_layout(user);
+ err = setup_sigframe_layout(user, false);
if (err)
return err;
@@ -936,3 +943,40 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
thread_flags = READ_ONCE(current_thread_info()->flags);
} while (thread_flags & _TIF_WORK_MASK);
}
+
+/*
+ * Determine the stack space required for guaranteed signal devliery.
+ * This function is used to populate AT_MINSIGSTKSZ at process startup.
+ */
+int get_minsigstksz(void)
+{
+ static __read_mostly atomic_t minsigstksz;
+
+ int ret;
+ struct rt_sigframe_user_layout user;
+
+ ret = atomic_read(&minsigstksz);
+ if (ret)
+ return ret;
+
+ init_user_layout(&user);
+ ret = setup_sigframe_layout(&user, true);
+
+ if (ret) {
+ WARN_ON(1);
+
+ ret = SIGSTKSZ;
+ } else {
+ ret = sigframe_size(&user) +
+ round_up(sizeof(struct frame_record), 16) +
+ 16; /* max alignment padding */
+ }
+
+ /*
+ * The computed value (ret) is invariant, so its value can be
+ * safely stored irrespective of whether some other racing
+ * task got there first:
+ */
+ atomic_set(&minsigstksz, ret);
+ return ret;
+}
--
2.1.4
^ permalink raw reply related
* [PATCH 0/2] arm64: Report signal frame size to userspace via auxv
From: Dave Martin @ 2018-05-08 10:43 UTC (permalink / raw)
To: linux-arm-kernel
Because SVE makes the arm64 signal frame size variable, userspace will
ultimately need a way to detect the size.
This series adds support for exposing this information via a new auxv
entry AT_MINSIGSTKSZ.
These patches are taken from [1], with minor updates. (They were RFC
in that series, but there has been no significant discussion or
objections raised in the meantime, and no change in the understanding
of the problem being addressed here. I'd like to get discussions for
binding this to glibc started.)
Changes since [1]:
* Cache the value computed to AT_MINSIGSTKSZ so that the effort of
computing it does not need to be repeated on every exec.
[1] [PATCH v5 00/30] ARM Scalable Vector Extension (SVE)
lists.infradead.org/pipermail/linux-arm-kernel/2017-October/539993.html
Dave Martin (2):
arm64: signal: Report signal frame size to userspace via auxv
arm64/sve: signal: Include SVE when computing AT_MINSIGSTKSZ
arch/arm64/include/asm/elf.h | 5 +++
arch/arm64/include/asm/processor.h | 3 ++
arch/arm64/include/uapi/asm/auxvec.h | 3 +-
arch/arm64/kernel/signal.c | 68 ++++++++++++++++++++++++++++++++----
4 files changed, 71 insertions(+), 8 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v5 10/14] KVM: arm64: Save host SVE context as appropriate
From: Marc Zyngier @ 2018-05-08 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525449935-31424-11-git-send-email-Dave.Martin@arm.com>
On 04/05/18 17:05, Dave Martin wrote:
> This patch adds SVE context saving to the hyp FPSIMD context switch
> path. This means that it is no longer necessary to save the host
> SVE state in advance of entering the guest, when in use.
>
> In order to avoid adding pointless complexity to the code, VHE is
> assumed if SVE is in use. VHE is an architectural prerequisite for
> SVE, so there is no good reason to turn CONFIG_ARM64_VHE off in
> kernels that support both SVE and KVM.
>
> Historically, software models exist that can expose the
> architecturally invalid configuration of SVE without VHE, so if
> this situation is detected this patch warns and refuses to create a
> VM. Doing this check at VM creation time avoids race issues
> between KVM and SVE initialisation.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
> ---
> arch/arm64/Kconfig | 7 +++++++
> arch/arm64/kvm/fpsimd.c | 1 -
> arch/arm64/kvm/hyp/switch.c | 21 +++++++++++++++++++--
> virt/kvm/arm/arm.c | 18 ++++++++++++++++++
> 4 files changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index eb2cf49..b0d3820 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1130,6 +1130,7 @@ endmenu
> config ARM64_SVE
> bool "ARM Scalable Vector Extension support"
> default y
> + depends on !KVM || ARM64_VHE
In that case, should we consider making ARM64_VHE "default y" as well,
as KVM is "default y" too?
Otherwise, I fear we end-up regressing existing configurations. Also,
you still have to check for the configuration at run time, so I'm not
immediately getting the point of this particular change.
> help
> The Scalable Vector Extension (SVE) is an extension to the AArch64
> execution state which complements and extends the SIMD functionality
> @@ -1155,6 +1156,12 @@ config ARM64_SVE
> booting the kernel. If unsure and you are not observing these
> symptoms, you should assume that it is safe to say Y.
>
> + CPUs that support SVE are architecturally required to support the
> + Virtualization Host Extensions (VHE), so the kernel makes no
> + provision for supporting SVE alongside KVM without VHE enabled.
> + Thus, you will need to enable CONFIG_ARM64_VHE if you want to support
> + KVM in the same kernel image.
> +
> config ARM64_MODULE_PLTS
> bool
> select HAVE_MOD_ARCH_SPECIFIC
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index bbc6889..91ad01f 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -59,7 +59,6 @@ int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
> */
> void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
> {
> - BUG_ON(system_supports_sve());
> BUG_ON(!current->mm);
>
> vcpu->arch.fp_enabled = false;
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 10f55d3..8009126 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -21,12 +21,14 @@
>
> #include <kvm/arm_psci.h>
>
> +#include <asm/cpufeature.h>
> #include <asm/kvm_asm.h>
> #include <asm/kvm_emulate.h>
> #include <asm/kvm_hyp.h>
> #include <asm/kvm_mmu.h>
> #include <asm/fpsimd.h>
> #include <asm/debug-monitors.h>
> +#include <asm/processor.h>
> #include <asm/thread_info.h>
>
> static bool __hyp_text update_fp_enabled(struct kvm_vcpu *vcpu)
> @@ -328,6 +330,8 @@ static bool __hyp_text __skip_instr(struct kvm_vcpu *vcpu)
> void __hyp_text __hyp_switch_fpsimd(u64 esr __always_unused,
> struct kvm_vcpu *vcpu)
> {
> + struct user_fpsimd_state *host_fpsimd = vcpu->arch.host_fpsimd_state;
> +
> if (has_vhe())
> write_sysreg(read_sysreg(cpacr_el1) | CPACR_EL1_FPEN,
> cpacr_el1);
> @@ -337,8 +341,21 @@ void __hyp_text __hyp_switch_fpsimd(u64 esr __always_unused,
>
> isb();
>
> - if (vcpu->arch.host_fpsimd_state) {
> - __fpsimd_save_state(vcpu->arch.host_fpsimd_state);
> + if (host_fpsimd) {
> + /*
> + * In the SVE case, VHE is assumed: it is enforced by
> + * Kconfig and kvm_arch_init_vm().
> + */
> + if (system_supports_sve() && vcpu->arch.host_sve_in_use) {
> + struct thread_struct *thread = container_of(
> + host_fpsimd,
> + struct thread_struct, uw.fpsimd_state);
> +
> + sve_save_state(sve_pffr(thread), &host_fpsimd->fpsr);
> + } else {
> + __fpsimd_save_state(vcpu->arch.host_fpsimd_state);
> + }
> +
> vcpu->arch.host_fpsimd_state = NULL;
> }
>
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 6cf499b..a7be7bf 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -16,6 +16,7 @@
> * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
> */
>
> +#include <linux/bug.h>
> #include <linux/cpu_pm.h>
> #include <linux/errno.h>
> #include <linux/err.h>
> @@ -41,6 +42,7 @@
> #include <asm/mman.h>
> #include <asm/tlbflush.h>
> #include <asm/cacheflush.h>
> +#include <asm/cpufeature.h>
> #include <asm/virt.h>
> #include <asm/kvm_arm.h>
> #include <asm/kvm_asm.h>
> @@ -120,6 +122,22 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> if (type)
> return -EINVAL;
>
> + /*
> + * VHE is a prerequisite for SVE in the Arm architecture, and
> + * Kconfig ensures that if system_supports_sve() here then
> + * CONFIG_ARM64_VHE is enabled, so if VHE support wasn't already
> + * detected and enabled, the CPU is architecturally
> + * noncompliant.
> + *
> + * Just in case this mismatch is seen, detect it, warn and give
> + * up. Supporting this forbidden configuration in Hyp would be
> + * pointless.
> + */
> + if (system_supports_sve() && !has_vhe()) {
> + kvm_pr_unimpl("Cannot create VMs on SVE system without VHE. Broken cpu?");
> + return -ENXIO;
> + }
You might as well fail the boot KVM initialization altogether, and not
wait for a VM to be created.
But I'm more concerned with the fact that we're now have a configuration
that drops functionalities on the floor, one way or another.
> +
> kvm->arch.last_vcpu_ran = alloc_percpu(typeof(*kvm->arch.last_vcpu_ran));
> if (!kvm->arch.last_vcpu_ran)
> return -ENOMEM;
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 7/7] ARM: dts: Fix DTC warnings
From: Robin Murphy @ 2018-05-08 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180506134352.2637-8-linus.walleij@linaro.org>
On 06/05/18 14:43, Linus Walleij wrote:
> The DTC was warning a lot about unit names etc, I think I fixed
> them all. One warning remains:
>
> arch/arm/boot/dts/gemini-rut1xx.dtb: Warning (unit_address_vs_reg):
> /memory: node has a reg or ranges property, but no unit name
>
> This comes up all the time even though memory is stated as
> memory at 0 for all boards, I guess this is a bug in the DTC
> syntax checker, like it cannot really differentiate between
> @0 and no unit name at all for the memory node.
That might be because it's pulling in skeleton.dtsi, since I think
"memory at 0" and "memory" are treated as distinct nodes, such that the
former from the board DTS no longer overrides the latter from skeleton
and you end up with both.
Robin.
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> arch/arm/boot/dts/gemini-dlink-dir-685.dts | 5 ++---
> arch/arm/boot/dts/gemini-dlink-dns-313.dts | 5 ++---
> arch/arm/boot/dts/gemini-nas4220b.dts | 12 +++++-------
> arch/arm/boot/dts/gemini-rut1xx.dts | 10 ++++------
> arch/arm/boot/dts/gemini-sq201.dts | 10 ++++------
> arch/arm/boot/dts/gemini-wbd111.dts | 15 +++++++--------
> arch/arm/boot/dts/gemini-wbd222.dts | 14 ++++++--------
> 7 files changed, 30 insertions(+), 41 deletions(-)
>
> diff --git a/arch/arm/boot/dts/gemini-dlink-dir-685.dts b/arch/arm/boot/dts/gemini-dlink-dir-685.dts
> index 89ce0d1916e3..fb5c954ab95a 100644
> --- a/arch/arm/boot/dts/gemini-dlink-dir-685.dts
> +++ b/arch/arm/boot/dts/gemini-dlink-dir-685.dts
> @@ -13,7 +13,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - memory {
> + memory at 0 {
> /* 128 MB SDRAM in 2 x Hynix HY5DU121622DTP-D43 */
> device_type = "memory";
> reg = <0x00000000 0x8000000>;
> @@ -26,8 +26,7 @@
>
> gpio_keys {
> compatible = "gpio-keys";
> - #address-cells = <1>;
> - #size-cells = <0>;
> +
> button-esc {
> debounce-interval = <50>;
> wakeup-source;
> diff --git a/arch/arm/boot/dts/gemini-dlink-dns-313.dts b/arch/arm/boot/dts/gemini-dlink-dns-313.dts
> index da78a0aa389a..d1329322b968 100644
> --- a/arch/arm/boot/dts/gemini-dlink-dns-313.dts
> +++ b/arch/arm/boot/dts/gemini-dlink-dns-313.dts
> @@ -15,7 +15,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - memory {
> + memory at 0 {
> /* 64 MB SDRAM in a Nanya NT5DS32M16BS-6K package */
> device_type = "memory";
> reg = <0x00000000 0x4000000>;
> @@ -32,8 +32,7 @@
>
> gpio_keys {
> compatible = "gpio-keys";
> - #address-cells = <1>;
> - #size-cells = <0>;
> +
> button-esc {
> debounce-interval = <50>;
> wakeup-source;
> diff --git a/arch/arm/boot/dts/gemini-nas4220b.dts b/arch/arm/boot/dts/gemini-nas4220b.dts
> index 9f78803b2456..963ea890c87f 100644
> --- a/arch/arm/boot/dts/gemini-nas4220b.dts
> +++ b/arch/arm/boot/dts/gemini-nas4220b.dts
> @@ -14,7 +14,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - memory { /* 128 MB */
> + memory at 0 { /* 128 MB */
> device_type = "memory";
> reg = <0x00000000 0x8000000>;
> };
> @@ -26,10 +26,8 @@
>
> gpio_keys {
> compatible = "gpio-keys";
> - #address-cells = <1>;
> - #size-cells = <0>;
>
> - button at 29 {
> + button-setup {
> debounce-interval = <50>;
> wakeup-source;
> linux,code = <KEY_SETUP>;
> @@ -37,7 +35,7 @@
> /* Conflict with TVC */
> gpios = <&gpio1 29 GPIO_ACTIVE_LOW>;
> };
> - button at 31 {
> + button-restart {
> debounce-interval = <50>;
> wakeup-source;
> linux,code = <KEY_RESTART>;
> @@ -49,13 +47,13 @@
>
> leds {
> compatible = "gpio-leds";
> - led at 28 {
> + led-orange-hdd {
> label = "nas4220b:orange:hdd";
> /* Conflict with TVC */
> gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
> default-state = "on";
> };
> - led at 30 {
> + led-green-os {
> label = "nas4220b:green:os";
> /* Conflict with TVC */
> gpios = <&gpio1 30 GPIO_ACTIVE_HIGH>;
> diff --git a/arch/arm/boot/dts/gemini-rut1xx.dts b/arch/arm/boot/dts/gemini-rut1xx.dts
> index a2f14ee37599..eb4f0bf074da 100644
> --- a/arch/arm/boot/dts/gemini-rut1xx.dts
> +++ b/arch/arm/boot/dts/gemini-rut1xx.dts
> @@ -14,7 +14,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - memory { /* 128 MB */
> + memory at 0 { /* 128 MB */
> device_type = "memory";
> reg = <0x00000000 0x8000000>;
> };
> @@ -26,10 +26,8 @@
>
> gpio_keys {
> compatible = "gpio-keys";
> - #address-cells = <1>;
> - #size-cells = <0>;
>
> - button at 28 {
> + button-setup {
> debounce-interval = <50>;
> wakeup-source;
> linux,code = <KEY_SETUP>;
> @@ -41,14 +39,14 @@
>
> leds {
> compatible = "gpio-leds";
> - led at 7 {
> + led-gsm {
> /* FIXME: add the LED color */
> label = "rut1xx::gsm";
> /* Conflict with ICE */
> gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
> default-state = "on";
> };
> - led at 31 {
> + led-power {
> /* FIXME: add the LED color */
> label = "rut1xx::power";
> /* Conflict with NAND CE0 */
> diff --git a/arch/arm/boot/dts/gemini-sq201.dts b/arch/arm/boot/dts/gemini-sq201.dts
> index 229c0267617a..e5cf9d1a98cd 100644
> --- a/arch/arm/boot/dts/gemini-sq201.dts
> +++ b/arch/arm/boot/dts/gemini-sq201.dts
> @@ -14,7 +14,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - memory { /* 128 MB */
> + memory at 0 { /* 128 MB */
> device_type = "memory";
> reg = <0x00000000 0x8000000>;
> };
> @@ -26,10 +26,8 @@
>
> gpio_keys {
> compatible = "gpio-keys";
> - #address-cells = <1>;
> - #size-cells = <0>;
>
> - button at 18 {
> + button-setup {
> debounce-interval = <50>;
> wakeup-source;
> linux,code = <KEY_SETUP>;
> @@ -41,14 +39,14 @@
>
> leds {
> compatible = "gpio-leds";
> - led at 20 {
> + led-green-info {
> label = "sq201:green:info";
> /* Conflict with parallel flash */
> gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
> default-state = "on";
> linux,default-trigger = "heartbeat";
> };
> - led at 31 {
> + led-green-usb {
> label = "sq201:green:usb";
> /* Conflict with parallel and NAND flash */
> gpios = <&gpio0 31 GPIO_ACTIVE_HIGH>;
> diff --git a/arch/arm/boot/dts/gemini-wbd111.dts b/arch/arm/boot/dts/gemini-wbd111.dts
> index b31a9189083f..29af86cd10f7 100644
> --- a/arch/arm/boot/dts/gemini-wbd111.dts
> +++ b/arch/arm/boot/dts/gemini-wbd111.dts
> @@ -14,7 +14,8 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - memory { /* 128 MB */
> + memory at 0 {
> + /* 128 MB */
> device_type = "memory";
> reg = <0x00000000 0x8000000>;
> };
> @@ -26,10 +27,8 @@
>
> gpio_keys {
> compatible = "gpio-keys";
> - #address-cells = <1>;
> - #size-cells = <0>;
>
> - button at 5 {
> + button-setup {
> debounce-interval = <50>;
> wakeup-source;
> linux,code = <KEY_SETUP>;
> @@ -42,25 +41,25 @@
> leds {
> compatible = "gpio-leds";
>
> - led at 1 {
> + led-red-l3 {
> label = "wbd111:red:L3";
> /* Conflict with TVC and extended parallel flash */
> gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> default-state = "off";
> };
> - led at 2 {
> + led-green-l4 {
> label = "wbd111:green:L4";
> /* Conflict with TVC and extended parallel flash */
> gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
> default-state = "off";
> };
> - led at 3 {
> + led-red-l4 {
> label = "wbd111:red:L4";
> /* Conflict with TVC and extended parallel flash */
> gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
> default-state = "off";
> };
> - led at 5 {
> + led-greeb-l3 {
> label = "wbd111:green:L3";
> /* Conflict with TVC and extended parallel flash */
> gpios = <&gpio0 5 GPIO_ACTIVE_HIGH>;
> diff --git a/arch/arm/boot/dts/gemini-wbd222.dts b/arch/arm/boot/dts/gemini-wbd222.dts
> index 0be867fbfc69..24e6ae3616f7 100644
> --- a/arch/arm/boot/dts/gemini-wbd222.dts
> +++ b/arch/arm/boot/dts/gemini-wbd222.dts
> @@ -14,7 +14,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - memory { /* 128 MB */
> + memory at 0 { /* 128 MB */
> device_type = "memory";
> reg = <0x00000000 0x8000000>;
> };
> @@ -26,10 +26,8 @@
>
> gpio_keys {
> compatible = "gpio-keys";
> - #address-cells = <1>;
> - #size-cells = <0>;
>
> - button at 5 {
> + button-setup {
> debounce-interval = <50>;
> wakeup-source;
> linux,code = <KEY_SETUP>;
> @@ -42,25 +40,25 @@
> leds {
> compatible = "gpio-leds";
>
> - led at 1 {
> + led-red-l3 {
> label = "wbd111:red:L3";
> /* Conflict with TVC and extended parallel flash */
> gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> default-state = "off";
> };
> - led at 2 {
> + led-green-l4 {
> label = "wbd111:green:L4";
> /* Conflict with TVC and extended parallel flash */
> gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
> default-state = "off";
> };
> - led at 3 {
> + led-red-l4 {
> label = "wbd111:red:L4";
> /* Conflict with TVC and extended parallel flash */
> gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
> default-state = "off";
> };
> - led at 5 {
> + led-green-l3 {
> label = "wbd111:green:L3";
> /* Conflict with TVC and extended parallel flash */
> gpios = <&gpio0 5 GPIO_ACTIVE_HIGH>;
>
^ 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