* [PATCH] crypto: arm/speck - fix building in Thumb2 mode
From: Eric Biggers @ 2018-06-18 22:33 UTC (permalink / raw)
To: linux-arm-kernel
Building the kernel with CONFIG_THUMB2_KERNEL=y and
CONFIG_CRYPTO_SPECK_NEON set fails with the following errors:
arch/arm/crypto/speck-neon-core.S: Assembler messages:
arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here -- `bic sp,#0xf'
arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here -- `bic sp,#0xf'
arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here -- `bic sp,#0xf'
arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here -- `bic sp,#0xf'
The problem is that the 'bic' instruction can't operate on the 'sp'
register in Thumb2 mode. Fix it by using a temporary register. This
isn't in the main loop, so the performance difference is negligible.
This also matches what aes-neonbs-core.S does.
Reported-by: Stefan Agner <stefan@agner.ch>
Fixes: ede9622162fa ("crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS")
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
arch/arm/crypto/speck-neon-core.S | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/crypto/speck-neon-core.S b/arch/arm/crypto/speck-neon-core.S
index 3c1e203e53b9..57caa742016e 100644
--- a/arch/arm/crypto/speck-neon-core.S
+++ b/arch/arm/crypto/speck-neon-core.S
@@ -272,9 +272,11 @@
* Allocate stack space to store 128 bytes worth of tweaks. For
* performance, this space is aligned to a 16-byte boundary so that we
* can use the load/store instructions that declare 16-byte alignment.
+ * For Thumb2 compatibility, don't do the 'bic' directly on 'sp'.
*/
- sub sp, #128
- bic sp, #0xf
+ sub r12, sp, #128
+ bic r12, #0xf
+ mov sp, r12
.if \n == 64
// Load first tweak
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: Mark Salter @ 2018-06-18 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0cbc68d5-9a8f-1734-4eea-d1f037927137@infradead.org>
On Mon, 2018-06-18 at 11:04 -0700, Geoff Levand wrote:
> Hi James,
>
> Thanks for all the comments, but my lack of access to an m400 platform, and
> my lack of knowledge about the m400 limits what I can comment on and what I
> can do.
I can take another look at this on an m400 here. I don't believe it is a
memory access to physical space with nothing attached to it. I seem to recall
an errata with xgene-1 where such accesses cause the cpu to halt. But I could
be misremembering that. I have no trouble believing the firmware ras code was
untested. It is probably some boilerplate code built in before ras was supported
in kernel. But the problem occurs early enough in boot where there can't be
that many things that would cause a problem on m400 and not mustang so I'll
look again.
>
> My motivation for submitting this fix was to enable CONFIG_ACPI_APEI in the
> Debian 10 kernel (for the new Cavium ThunderX2 based systems). The Debian
> maintainers wanted to either have an upstream kernel fix for this m400 APEI
> problem or to disable CONFIG_ACPI_APEI. The later would be unfortunate. It
> means users would need to have custom kernels to get APEI support or go
> without.
>
> Comments follow.
>
> On 06/18/2018 09:18 AM, James Morse wrote:
> > On 15/06/18 18:17, Geoff Levand wrote:
> >
> > From:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1574718
> >
> > This is tripped by the ghes_probe() call, it finds an error has already occurred
> > before ghes code is initialized.
> >
> > Does this still happen if you compile without CONFIG_PCI? (that is easily half
> > the dmesg that has happened before this point).
> > Disabling CONFIG_EFIVAR_FS would be interesting too, as that is firmware-code we
> > can't fix bugs in.
>
> Sorry, no m400 to test these on, but looking at the code, I would say it doesn't
> occur if CONFIG_PCI=n.
>
> > Your argument here is the that the firmware-vendor only build-tested their code,
> > and never noticed it notifies a fatal exception on startup. I find this hard to
> > believe, especially as these systems don't have EL3.
> >
> > It's much more likely a driver is causing this, possibly because of bad data in
> > the firmware tables. I'd like to quirk the driver, so we can fix the next error
> > like this, as opposed to blindly continuing.
>
> That sounds OK, but which driver?
>
> > If it really is firmware, what is it doing that causes this error, and where
> > does it run? Disabling APEI is just reacting after the error has occurred, when
> > we could prevent it happening.
> >
> > I can't reproduce this on a Mustang. I assume its the different ACPI tables, not
> > the kernel-config.
>
> From what I understand this is only on the m400, not the Mustang.
>
> > > I just put together this patch to unify things and have a
> > > common 'upstream' fix.
> >
> > Wouldn't passing 'hest_disable' on the cmdline do the same for all kernel versions?
>
> Yes, the current patch essentially just sets hest_disable when an m400 is
> detected. The cmdline work-around is what some have been using, but is
> not an acceptable solution for the Debian maintainers. See
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900581
>
> > > On 06/15/2018 04:14 AM, James Morse wrote:
> > > > On 13/06/18 19:22, Geoff Levand wrote:
> > > > > Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
> > > > > a work-around for HPE ProLiant m400 APEI firmware problems.
> > > > >
> > > > > The work-around disables APEI when CONFIG_ACPI_APEI is set and
> > > > > m400 firmware is detected. Without this fixup m400 systems
> > > > > experience errors like these on startup:
> > > > >
> > > > > [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
> > > > > [Hardware Error]: event severity: fatal
> > > > > [Hardware Error]: Error 0, type: fatal
> > > > > [Hardware Error]: section_type: memory error
> > > > > [Hardware Error]: error_status: 0x0000000000001300
> > > >
> > > > "Access to a memory address which is not mapped to any component"
> > > >
> > > >
> > > > > [Hardware Error]: error_type: 10, invalid address
> > > > > Kernel panic - not syncing: Fatal hardware error!
> > > >
> > > > Why is this a problem?
> > > >
> > > > Surely this is a valid description of an error.
> > >
> > > The firmware bug causes this failure, not bad hardware.
> >
> > I'm not talking about bad hardware here. What I think is happening is a software
> > bug is causing the CPU to make a bad access, which the RAS mechanism is
> > reporting like this because software would never be stupid enough to access an
> > address which is not mapped to any component! The RAS stuff believes this must
> > be address corruption.
> >
> > I think this is a linux-driver bug, or a typo in the firmware tables, that cause
> > $non_existent_address to be mapped and probed.
>
> From what I know about it the problem is in the access of the firmware tables,
> and that corrupted data is retrieved. But I am not sure, as there are so many
> reported m400 firmware problems it is hard to tell what exactly is what.
>
> > > > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > > > > index 7b09487ff8fb..3c315c2c7476 100644
> > > > > --- a/arch/arm64/kernel/acpi.c
> > > > > +++ b/arch/arm64/kernel/acpi.c
> > > > > +
> > > > > + if (!IS_ENABLED(CONFIG_ACPI_APEI) || hest_disable != HEST_ENABLED)
> > > > > + return;
> > > > > +
> > > > > + status = acpi_get_table(ACPI_SIG_HEST, 0, &header);
> > > > > +
> > > > > + if (ACPI_SUCCESS(status) && !strncmp(header->oem_id, "HPE ", 6) &&
> > > > > + !strncmp(header->oem_table_id, "ProLiant", 8) &&
> > > > You should match the affected range of OEM table revisions too, that way a
> > > > firmware upgrade should start working, instead of being permanently disabled
> > > > because we think its unlikely.
> > >
> > > The m400 has reached end of life. No one really expects to see any firmware
> > > update. I don't know what the effected OEM table revisions are, and I don't
> > > think there is an active platform maintainer who could give that info either.
> > >
> > > If someone can provide the info. I'll update the fix.
> >
> > We can start with the version you have. You mention distro's have their own
> > fixes, hopefully they can supply the missing range of values.
>
> It seems you are living in a dream world...
>
> > > > > + MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM) {
> > > >
> > > > How is the CPU implementer relevant?
> > >
> > > That was just a copy of what other fixes had. Should I remove it?
> >
> > The conclusion in the rest of this thread was HPE also produces ProLiant boxes
> > with a (presumably) identical HEST, but a totally different architecture.
> >
> > Matching the DMI platform name as well would work round this. (or somewhere only
> > arm64 builds, with an appropriate comment in case we move it).
> >
> >
> > > > Nothing arch-specific here. You're adding this to arch/arm64 because
> > > > drivers/acpi/apei doesn't have an existing quirks table?
> > >
> > > There was a fix submitted that had it in drivers/acpi/scan.c, but the
> > > ACPI maintainer said he didn't want the fix in the main ACPI code.
> >
> > Specifically about a HID-hack in the core device enumeration code, as opposed to
> > in the driver that claims it.
> >
> >
> > > See:
> > >
> > > https://lkml.org/lkml/2018/4/19/1020 (ACPI / scan: Fix regression related to X-Gene UARTs)
> > > 'some X-Gene based platforms (Mustang and M400) with invalid DSDT.'
> >
> > ... sounds familiar ...
> >
> > And:
> > https://bugzilla.redhat.com/attachment.cgi?id=1144903&action=diff
> >
> > Fixes a typo in firmware description of the GIC.
> >
> > Why do we think this is a new kind of firmware bug, and not a repeat of the last
> > two? The only difference is this is being caught by the RAS code.
>
> It could very well be.
>
> > > The m400 is an arm64 platform, so it seems most appropriate to
> > > have it in arch/arm64/kernel/acpi.c.
> >
> > We don't keep all drivers under arch/arm64, I'd really like to find the driver
> > that is causing this, and quirk it there.
> >
> > If we have to bolt the hest-stable-door, drivers/acpi/apei/hest.c looks better,
> > it at least doesn't have to bodge around hest_disabled not being exposed in a
> > compatible way. If the maintainer objects, (as x86 hasn't had to do this yet),
> > then we can try drivers/acpi/arm64/hest_quirks.c.
>
> We need to call acpi_fixup_m400_quirks early enough to get hest_disable set
> before it is used. To do that from drivers/acpi/ code we would need have
> it as arch_initcall, or still call it from acpi_boot_table_init. I think
> having it as a static routine and the call in arch/arm64/kernel/acpi.c is
> cleaner.
>
> > When only once architecture had to quirk stuff based on the ACPI tables, the
> > arch-code was a suitable dumping ground. Now there is more than one, we should
> > do things in a way they are useful to both architectures.
>
> As I mentioned in the opening, I don't have access to m400 equipment. There is
> little I can do. I could move acpi_fixup_m400_quirks into
> drivers/acpi/apei/hest.c and submit that to the ACPI maintainer, but based on
> https://lkml.org/lkml/2018/4/19/1020, I don't think it would be accepted.
>
> -Geoff
>
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: add 96boards RK3399 Ficus board
From: Ezequiel Garcia @ 2018-06-18 22:08 UTC (permalink / raw)
To: linux-arm-kernel
The RK3399 Ficus board is an Enterprise Edition board
manufactured by Vamrs Ltd., based on the Rockchip RK3399 SoC.
The board exposes a bunch of nice peripherals, including
SATA, HDMI, MIPI CSI, Ethernet, WiFi, USB 2.0, USB 3.0
and PCIe.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
I am not including USB support because I cannot seem
to make it work.
[ 1.677293] dwc3 fe800000.dwc3: Failed to get clk 'ref': -2
[ 1.677937] dwc3 fe800000.dwc3: Configuration mismatch. dr_mode forced to host
[ 1.678602] dwc3 fe800000.dwc3: failed to initialize core
[ 1.679409] dwc3 fe900000.dwc3: Failed to get clk 'ref': -2
[ 1.679988] dwc3 fe900000.dwc3: failed to initialize core
I am under the impression it is related to:
commit fe8abf332b8f66868013cfcd6bfe727136a2ab5f
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Wed May 16 11:41:07 2018 +0900
usb: dwc3: support clocks and resets for DWC3 core
Any ideas? Would like to sort out the USB issue before
merging.
Also, I should probably split the rk3399.dtsi change.
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3399-ficus.dts | 564 ++++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +
3 files changed, 574 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 48a83f882947..2811fb701f12 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-ficus.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
new file mode 100644
index 000000000000..17471b4b7a14
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
@@ -0,0 +1,564 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ model = "96boards RK3399 Ficus";
+ compatible = "vamrs,ficus", "rockchip,rk3399";
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <125000000>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+
+ usb_typec_vbus: usb-typec-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "typec-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio1 3 GPIO_ACTIVE_HIGH>;
+ };
+
+ vcc1v8_s0: vcc1v8-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc1v8_s0";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ vcc_sys: vcc-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ vcc_phy: vcc-phy-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_phy";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
+ vcc3v3_pcie: vcc3v3-pcie-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio1 24 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_drv>;
+ regulator-boot-on;
+ regulator-name = "vcc3v3_pcie";
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ vcc5v0_host: vcc5v0-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio4 27 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&host_vbus_drv>;
+ regulator-name = "vcc5v0_host";
+ regulator-always-on;
+ };
+
+ vdd_log: vdd-log {
+ compatible = "pwm-regulator";
+ pwms = <&pwm2 0 25000 0>;
+ regulator-name = "vdd_log";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ /* for rockchip boot on */
+ rockchip,pwm_id= <2>;
+ rockchip,pwm_voltage = <900000>;
+
+ vin-supply = <&vcc_sys>;
+ };
+
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+ status = "okay";
+};
+
+&gmac {
+ assigned-clocks = <&cru SCLK_RMII_SRC>;
+ assigned-clock-parents = <&clkin_gmac>;
+ clock_in_out = "input";
+ phy-supply = <&vcc_phy>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 50000>;
+ tx_delay = <0x28>;
+ rx_delay = <0x11>;
+ status = "okay";
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ i2c-scl-rising-time-ns = <168>;
+ i2c-scl-falling-time-ns = <4>;
+ clock-frequency = <400000>;
+
+ vdd_cpu_b: syr827 at 40 {
+ status = "okay";
+ compatible = "silergy,syr827";
+ reg = <0x40>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu_b";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: regulator at 41 {
+ compatible = "silergy,syr828";
+ reg = <0x41>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_gpu";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ fusb0: fusb30x at 22 {
+ vbus-supply = <&usb_typec_vbus>;
+ compatible = "fairchild,fusb302";
+ reg = <0x22>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&fusb0_int>;
+ int-n-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+ };
+
+ rk808: pmic at 1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ wakeup-source;
+ #clock-cells = <1>;
+ clock-output-names = "xin32k", "rk808-clkout2";
+
+ vcc1-supply = <&vcc_sys>;
+ vcc2-supply = <&vcc_sys>;
+ vcc3-supply = <&vcc_sys>;
+ vcc4-supply = <&vcc_sys>;
+ vcc6-supply = <&vcc_sys>;
+ vcc7-supply = <&vcc_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc_sys>;
+ vcc10-supply = <&vcc_sys>;
+ vcc11-supply = <&vcc_sys>;
+ vcc12-supply = <&vcc3v3_sys>;
+ vddio-supply = <&vcc_1v8>;
+
+ regulators {
+ vdd_center: DCDC_REG1 {
+ regulator-name = "vdd_center";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_l: DCDC_REG2 {
+ regulator-name = "vdd_cpu_l";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ //regulator-ramp-delay = <6001>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_1v8: DCDC_REG4 {
+ regulator-name = "vcc_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc1v8_dvp: LDO_REG1 {
+ regulator-name = "vcc1v8_dvp";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcca1v8_hdmi: LDO_REG2 {
+ regulator-name = "vcca1v8_hdmi";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcca_1v8: LDO_REG3 {
+ regulator-name = "vcca_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_sd: LDO_REG4 {
+ regulator-name = "vcc_sd";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcc3v0_sd: LDO_REG5 {
+ regulator-name = "vcc3v0_sd";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcc_1v5: LDO_REG6 {
+ regulator-name = "vcc_1v5";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1500000>;
+ };
+ };
+
+ vcca0v9_hdmi: LDO_REG7 {
+ regulator-name = "vcca0v9_hdmi";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <900000>;
+ };
+ };
+
+ vcc_3v0: LDO_REG8 {
+ regulator-name = "vcc_3v0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcc3v3_s3: SWITCH_REG1 {
+ regulator-name = "vcc3v3_s3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc3v3_s0: SWITCH_REG2 {
+ regulator-name = "vcc3v3_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c3 {
+ status = "okay";
+};
+
+&i2c4 {
+ status = "okay";
+};
+
+&io_domains {
+ status = "okay";
+
+ bt656-supply = <&vcc1v8_s0>; /* bt656_gpio2ab_ms */
+ audio-supply = <&vcc1v8_s0>; /* audio_gpio3d4a_ms */
+ sdmmc-supply = <&vcc_sd>; /* sdmmc_gpio4b_ms */
+ gpio1830-supply = <&vcc_3v0>; /* gpio1833_gpio4cd_ms */
+};
+
+&pcie_phy {
+ status = "okay";
+};
+
+&pcie0 {
+ ep-gpios = <&gpio4 RK_PD4 GPIO_ACTIVE_HIGH>;
+ num-lanes = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_clkreqn_cpm>;
+ status = "okay";
+};
+
+&pmu_io_domains {
+ pmu1830-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&pinctrl {
+ gmac {
+ rgmii_sleep_pins: rgmii-sleep-pins {
+ rockchip,pins =
+ <3 15 RK_FUNC_GPIO &pcfg_output_low>;
+ };
+ };
+
+ sdmmc {
+ sdmmc_bus1: sdmmc-bus1 {
+ rockchip,pins =
+ <4 8 RK_FUNC_1 &pcfg_pull_up_8ma>;
+ };
+
+ sdmmc_bus4: sdmmc-bus4 {
+ rockchip,pins =
+ <4 8 RK_FUNC_1 &pcfg_pull_up_8ma>,
+ <4 9 RK_FUNC_1 &pcfg_pull_up_8ma>,
+ <4 10 RK_FUNC_1 &pcfg_pull_up_8ma>,
+ <4 11 RK_FUNC_1 &pcfg_pull_up_8ma>;
+ };
+
+ sdmmc_clk: sdmmc-clk {
+ rockchip,pins =
+ <4 12 RK_FUNC_1 &pcfg_pull_none_18ma>;
+ };
+
+ sdmmc_cmd: sdmmc-cmd {
+ rockchip,pins =
+ <4 13 RK_FUNC_1 &pcfg_pull_up_8ma>;
+ };
+ };
+
+ pcie {
+ pcie_drv: pcie-drv {
+ rockchip,pins =
+ <1 24 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins =
+ <1 21 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ vsel1_gpio: vsel1-gpio {
+ rockchip,pins =
+ <1 17 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ vsel2_gpio: vsel2-gpio {
+ rockchip,pins =
+ <1 14 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ usb2 {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins =
+ <4 27 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ fusb30x {
+ fusb0_int: fusb0-int {
+ rockchip,pins =
+ <1 2 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&pwm3 {
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ non-removable;
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ clock-frequency = <100000000>;
+ clock-freq-min-max = <100000 100000000>;
+ disable-wp;
+ sd-uhs-sdr104;
+ vqmmc-supply = <&vcc_sd>;
+ card-detect-delay = <800>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_cts>;
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+
+&vopb {
+ status = "okay";
+};
+
+&vopb_mmu {
+ status = "okay";
+};
+
+&vopl {
+ status = "okay";
+};
+
+&vopl_mmu {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index adb037cd80fe..7169603590f5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1923,6 +1923,11 @@
drive-strength = <12>;
};
+ pcfg_pull_none_18ma: pcfg-pull-none-18ma {
+ bias-disable;
+ drive-strength = <18>;
+ };
+
pcfg_pull_up_8ma: pcfg-pull-up-8ma {
bias-pull-up;
drive-strength = <8>;
@@ -1948,6 +1953,10 @@
drive-strength = <13>;
};
+ pcfg_output_low: pcfg-output-low {
+ output-low;
+ };
+
clock {
clk_32k: clk-32k {
rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>;
--
2.17.1
^ permalink raw reply related
* [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS
From: Ard Biesheuvel @ 2018-06-18 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618215657.GB8022@google.com>
On 18 June 2018 at 23:56, Eric Biggers <ebiggers@google.com> wrote:
> On Sun, Jun 17, 2018 at 01:10:41PM +0200, Ard Biesheuvel wrote:
>> >>>>> +
>> >>>>> + // One-time XTS preparation
>> >>>>> +
>> >>>>> + /*
>> >>>>> + * Allocate stack space to store 128 bytes worth of tweaks. For
>> >>>>> + * performance, this space is aligned to a 16-byte boundary so that we
>> >>>>> + * can use the load/store instructions that declare 16-byte alignment.
>> >>>>> + */
>> >>>>> + sub sp, #128
>> >>>>> + bic sp, #0xf
>> >>>>
>> >>>>
>> >>>> This fails here when building with CONFIG_THUMB2_KERNEL=y
>> >>>>
>> >>>> AS arch/arm/crypto/speck-neon-core.o
>> >>>>
>> >>>> arch/arm/crypto/speck-neon-core.S: Assembler messages:
>> >>>>
>> >>>> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here --
>> >>>> `bic sp,#0xf'
>> >>>> arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here --
>> >>>> `bic sp,#0xf'
>> >>>> arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here --
>> >>>> `bic sp,#0xf'
>> >>>> arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here --
>> >>>> `bic sp,#0xf'
>> >>>>
>> >>>> In a quick hack this change seems to address it:
>> >>>>
>> >>>>
>> >>>> - sub sp, #128
>> >>>> - bic sp, #0xf
>> >>>> + mov r6, sp
>> >>>> + sub r6, #128
>> >>>> + bic r6, #0xf
>> >>>> + mov sp, r6
>> >>>>
>> >>>> But there is probably a better solution to address this.
>> >>>>
>> >>>
>> >>> Given that there is no NEON on M class cores, I recommend we put something like
>> >>>
>> >>> THUMB(bx pc)
>> >>> THUMB(nop.w)
>> >>> THUMB(.arm)
>> >>>
>> >>> at the beginning and be done with it.
>> >>
>> >> I mean nop.n or just nop, of course, and we may need a '.align 2' at
>> >> the beginning as well.
>> >
>> > Wouldn't it be preferable to have it assemble it in Thumb2 too? It seems
>> > that bic sp,#0xf is the only issue...
>> >
>>
>> Well, in general, yes. In the case of NEON code, not really, since the
>> resulting code will not be smaller anyway, because the Thumb2 NEON
>> opcodes are all 4 bytes. Also, Thumb2-only cores don't have NEON
>> units, so all cores that this code can run on will be able to run in
>> ARM mode.
>>
>> So from a maintainability pov, having code that only assembles in one
>> way is better than having code that must compile both to ARM and to
>> Thumb2 opcodes.
>>
>> Just my 2 cents, anyway.
>
> I don't have too much of a preference, though Stefan's suggested 4 instructions
> can be reduced to 3, which also matches what aes-neonbs-core.S does:
>
> sub r12, sp, #128
> bic r12, #0xf
> mov sp, r12
>
> Ard, is the following what you're suggesting instead?
>
Yes, but after looking at the actual code, I prefer the change above.
The access occurs only once, not in the loop so the additional
instructions should not affect performance.
Apologies for the noise.
> diff --git a/arch/arm/crypto/speck-neon-core.S b/arch/arm/crypto/speck-neon-core.S
> index 3c1e203e53b9..c989ce3dc057 100644
> --- a/arch/arm/crypto/speck-neon-core.S
> +++ b/arch/arm/crypto/speck-neon-core.S
> @@ -8,6 +8,7 @@
> */
>
> #include <linux/linkage.h>
> +#include <asm/assembler.h>
>
> .text
> .fpu neon
> @@ -233,6 +234,12 @@
> * nonzero multiple of 128.
> */
> .macro _speck_xts_crypt n, decrypting
> +
> + .align 2
> + THUMB(bx pc)
> + THUMB(nop)
> + THUMB(.arm)
> +
> push {r4-r7}
> mov r7, sp
>
> @@ -413,6 +420,8 @@
> mov sp, r7
> pop {r4-r7}
> bx lr
> +
> + THUMB(.thumb)
> .endm
>
> ENTRY(speck128_xts_encrypt_neon)
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: sdm845: Add rpmh-rsc node
From: Lina Iyer @ 2018-06-18 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618215051.156270-1-dianders@chromium.org>
Thanks for the quick spin Doug.
On Mon, Jun 18 2018 at 15:51 -0600, Douglas Anderson wrote:
>This adds the rpmh-rsc node to sdm845 based on the examples in the
>bindings.
>
>Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Lina Iyer <ilina@codeaurora.org>
>---
>
>Changes in v2:
>- Fixed ordering of tcs-config as per Lina.
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
>diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>index cd308b84bed7..43a182fb42c9 100644
>--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>@@ -7,6 +7,7 @@
>
> #include <dt-bindings/clock/qcom,gcc-sdm845.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
>+#include <dt-bindings/soc/qcom,rpmh-rsc.h>
>
> / {
> interrupt-parent = <&intc>;
>@@ -984,6 +985,24 @@
> #mbox-cells = <1>;
> };
>
>+ apps_rsc: rsc at 179c0000 {
>+ label = "apps_rsc";
>+ compatible = "qcom,rpmh-rsc";
>+ reg = <0x179c0000 0x10000>,
>+ <0x179d0000 0x10000>,
>+ <0x179e0000 0x10000>;
>+ reg-names = "drv-0", "drv-1", "drv-2";
>+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
>+ qcom,tcs-offset = <0xd00>;
>+ qcom,drv-id = <2>;
>+ qcom,tcs-config = <ACTIVE_TCS 2>,
>+ <SLEEP_TCS 3>,
>+ <WAKE_TCS 3>,
>+ <CONTROL_TCS 1>;
>+ };
>+
> intc: interrupt-controller at 17a00000 {
> compatible = "arm,gic-v3";
> #address-cells = <1>;
>--
>2.18.0.rc1.244.gcf134e6275-goog
>
^ permalink raw reply
* [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS
From: Eric Biggers @ 2018-06-18 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8OnTY7ezbkU5-EzVHp3vvPr_okkOoWfOjkdxhSqSqhBg@mail.gmail.com>
On Sun, Jun 17, 2018 at 01:10:41PM +0200, Ard Biesheuvel wrote:
> >>>>> +
> >>>>> + // One-time XTS preparation
> >>>>> +
> >>>>> + /*
> >>>>> + * Allocate stack space to store 128 bytes worth of tweaks. For
> >>>>> + * performance, this space is aligned to a 16-byte boundary so that we
> >>>>> + * can use the load/store instructions that declare 16-byte alignment.
> >>>>> + */
> >>>>> + sub sp, #128
> >>>>> + bic sp, #0xf
> >>>>
> >>>>
> >>>> This fails here when building with CONFIG_THUMB2_KERNEL=y
> >>>>
> >>>> AS arch/arm/crypto/speck-neon-core.o
> >>>>
> >>>> arch/arm/crypto/speck-neon-core.S: Assembler messages:
> >>>>
> >>>> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here --
> >>>> `bic sp,#0xf'
> >>>> arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here --
> >>>> `bic sp,#0xf'
> >>>> arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here --
> >>>> `bic sp,#0xf'
> >>>> arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here --
> >>>> `bic sp,#0xf'
> >>>>
> >>>> In a quick hack this change seems to address it:
> >>>>
> >>>>
> >>>> - sub sp, #128
> >>>> - bic sp, #0xf
> >>>> + mov r6, sp
> >>>> + sub r6, #128
> >>>> + bic r6, #0xf
> >>>> + mov sp, r6
> >>>>
> >>>> But there is probably a better solution to address this.
> >>>>
> >>>
> >>> Given that there is no NEON on M class cores, I recommend we put something like
> >>>
> >>> THUMB(bx pc)
> >>> THUMB(nop.w)
> >>> THUMB(.arm)
> >>>
> >>> at the beginning and be done with it.
> >>
> >> I mean nop.n or just nop, of course, and we may need a '.align 2' at
> >> the beginning as well.
> >
> > Wouldn't it be preferable to have it assemble it in Thumb2 too? It seems
> > that bic sp,#0xf is the only issue...
> >
>
> Well, in general, yes. In the case of NEON code, not really, since the
> resulting code will not be smaller anyway, because the Thumb2 NEON
> opcodes are all 4 bytes. Also, Thumb2-only cores don't have NEON
> units, so all cores that this code can run on will be able to run in
> ARM mode.
>
> So from a maintainability pov, having code that only assembles in one
> way is better than having code that must compile both to ARM and to
> Thumb2 opcodes.
>
> Just my 2 cents, anyway.
I don't have too much of a preference, though Stefan's suggested 4 instructions
can be reduced to 3, which also matches what aes-neonbs-core.S does:
sub r12, sp, #128
bic r12, #0xf
mov sp, r12
Ard, is the following what you're suggesting instead?
diff --git a/arch/arm/crypto/speck-neon-core.S b/arch/arm/crypto/speck-neon-core.S
index 3c1e203e53b9..c989ce3dc057 100644
--- a/arch/arm/crypto/speck-neon-core.S
+++ b/arch/arm/crypto/speck-neon-core.S
@@ -8,6 +8,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
.text
.fpu neon
@@ -233,6 +234,12 @@
* nonzero multiple of 128.
*/
.macro _speck_xts_crypt n, decrypting
+
+ .align 2
+ THUMB(bx pc)
+ THUMB(nop)
+ THUMB(.arm)
+
push {r4-r7}
mov r7, sp
@@ -413,6 +420,8 @@
mov sp, r7
pop {r4-r7}
bx lr
+
+ THUMB(.thumb)
.endm
ENTRY(speck128_xts_encrypt_neon)
^ permalink raw reply related
* Dynamic ftrace self test broken on ARM
From: Steven Rostedt @ 2018-06-18 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <65fb14b356bc0a414f1fe5cf5c6eb395@agner.ch>
On Mon, 18 Jun 2018 23:09:04 +0200
Stefan Agner <stefan@agner.ch> wrote:
> Hi,
>
> On a ARM (i.MX 7) I noticed today that the kernel crashes after dynamic
> ftrace self test. I tried v4.18-rc1 first, but it seems that at least
> also v4.17 is affected.
>
> VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
> max_idle_ns: 19112604462750000 ns
> futex hash table entries: 512 (order: 3, 32768 bytes)
> Running postponed tracer tests:
> Testing tracer function: PASSED
> Testing dynamic ftrace: PASSED
> Testing dynamic ftrace ops #1:
> (1 0 1 0 0)
> (1 1 2 0 0)
> (2 1 3 0 93620)
> (2 2 4 0 93807) PASSED
> Testing dynamic ftrace ops #2:
> (1 0 1 96630 0)
> (1 1 2 96804 0)
> (2 1 3 1 342)
> (2 2 4 121 462) PASSED
> Testing ftrace recursion: PASSED
> Testing ftrace recursion safe: PASSED
> Testing ftrace regs: PASSED
> Testing tracer nop: PASSED
> Testing tracer function_graph: PASSED
> pinctrl core: initialized pinctrl subsystem
> Unable to handle kernel paging request at virtual address c0ca14e4
> pgd = (ptrval)
> [c0ca14e4] *pgd=80c1940e(bad)
> Internal error: Oops: 80d [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.17.0 #564
> Hardware name: Freescale i.MX7 Dual (Device Tree)
> PC is at skb_init+0x50/0x7c
> LR is at kmem_cache_create_usercopy+0x10c/0x320
> pc : [<c0e63b80>] lr : [<c023bd5c>] psr: 60000013
> sp : dc11be98 ip : dc11be58 fp : dc11bebc
> r10: c0e006f0 r9 : c0e82820 r8 : c0faa8c0
> r7 : c0e63a10 r6 : 00000000 r5 : 00000000 r4 : c0ca14e4
> r3 : c0eb72c8 r2 : 00000000 r1 : 1ea8b000 r0 : dc0eef00
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 8000406a DAC: 00000051
> Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
> Stack: (0xdc11be98 to 0xdc11c000)
> be80: 00000018
> 00000030
> bea0: 00000000 c07fda4c 00000000 ffffe000 dc11bedc dc11bec0 c0e63a38
> c0e63b3c
> bec0: c0e5d488 c0170c64 c0fa7140 c0fa7140 dc11bf44 dc11bee0 c0103080
> c0e63a1c
> bee0: c0145d74 c0e006fc c0bf3c00 c0bf3ca4 c0bf3cf0 c0c03b98 00000000
> c0bf3c7c
> bf00: 00000001 00000001 c0bf6c04 c0cf0b68 dffffc66 00000000 00000000
> c0fa7140
> bf20: c0e82844 00000002 c0fa7140 c0eb6264 00000002 c0faa8c0 dc11bf94
> dc11bf48
> bf40: c0e011d8 c0103038 00000001 00000001 00000000 c0e006f0 00000000
> c0f09fc0
> bf60: c0cf0b68 000000dc c0989c58 00000000 c0989c58 00000000 00000000
> 00000000
> bf80: 00000000 00000000 dc11bfac dc11bf98 c0989c70 c0e00f74 00000000
> c0989c58
> bfa0: 00000000 dc11bfb0 c01010e8 c0989c64 00000000 00000000 00000000
> 00000000
> bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000
> bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000
> 00000000
> [<c0e63b80>] (skb_init) from [<c0e63a38>] (sock_init+0x28/0xc8)
> [<c0e63a38>] (sock_init) from [<c0103080>] (do_one_initcall+0x54/0x1e8)
> [<c0103080>] (do_one_initcall) from [<c0e011d8>]
> (kernel_init_freeable+0x270/0x308)
> [<c0e011d8>] (kernel_init_freeable) from [<c0989c70>]
> (kernel_init+0x18/0x124)
> [<c0989c70>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
> Exception stack(0xdc11bfb0 to 0xdc11bff8)
> bfa0: 00000000 00000000 00000000
> 00000000
> bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000
> bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> Code: e58d3000 e3a010b8 e3a03a42 ebcf6033 (e5840000)
> ---[ end trace fff84001ba23c9c9 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [ 2.292924]
> CPU1: stopping
> CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.17.0 #564
> Hardware name: Freescale i.MX7 Dual (Device Tree)
> [<c01128a4>] (unwind_backtrace) from [<c010d868>] (show_stack+0x20/0x24)
> [<c010d868>] (show_stack) from [<c0975590>] (dump_stack+0x90/0xa4)
> [<c0975590>] (dump_stack) from [<c0110608>] (handle_IPI+0x2dc/0x2fc)
> [<c0110608>] (handle_IPI) from [<c010233c>] (gic_handle_irq+0x9c/0xa0)
> [<c010233c>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0x6c/0x90)
> Exception stack(0xdc14df18 to 0xdc14df60)
> df00: 00000000
> 00000324
> df20: df957420 c011c4c0 ffffe000 c0f05d28 c0f05d6c 00000002 00000000
> c0f05d80
> df40: 00000000 dc14df74 dc14df78 dc14df68 c0109938 c010993c 60000013
> ffffffff
> [<c0101a0c>] (__irq_svc) from [<c010993c>] (arch_cpu_idle+0x48/0x4c)
> [<c010993c>] (arch_cpu_idle) from [<c098f81c>]
> (default_idle_call+0x30/0x3c)
> [<c098f81c>] (default_idle_call) from [<c01566a4>] (do_idle+0x1bc/0x284)
> [<c01566a4>] (do_idle) from [<c0156a18>] (cpu_startup_entry+0x28/0x30)
> [<c0156a18>] (cpu_startup_entry) from [<c01100b0>]
> (secondary_start_kernel+0x158/0x164)
> [<c01100b0>] (secondary_start_kernel) from [<8010274c>] (0x8010274c)
> ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
> ]---
>
> I tested with imx_v6_v7_defconfig and enabled the following options:
>
> CONFIG_DYNAMIC_FTRACE=y
>
> CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
>
> CONFIG_FTRACE_MCOUNT_RECORD=y
>
> CONFIG_FTRACE_SELFTEST=y
>
> CONFIG_FTRACE_STARTUP_TEST=y
>
> I guess startup test should leave the kernel unencumbered?
>
>
I'm guessing that it boots fine with CONFIG_FTRACE_STARTUP_TEST=n? Can
you try disable the tracers to see if it's the function graph or
function tracer that is causing the issue? That is, turn off
CONFIG_FUNCTION_GRAPH_TRACER and test it again, and if that crashes,
turn off CONFIG_FUNCTION_TRACER to make sure the crash goes away there
too.
-- Steve
^ permalink raw reply
* [PATCH 1/2] arm64: dts: sdm845: Add rpmh-rsc node
From: Doug Anderson @ 2018-06-18 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618212414.GI21724@codeaurora.org>
Hi,
On Mon, Jun 18, 2018 at 2:24 PM, Lina Iyer <ilina@codeaurora.org> wrote:
> On Mon, Jun 18 2018 at 14:56 -0600, Douglas Anderson wrote:
>>
>> This adds the rpmh-rsc node to sdm845 based on the examples in the
>> bindings.
>>
>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>> ---
>>
>> arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index cd308b84bed7..19b006293d3b 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -7,6 +7,7 @@
>>
>> #include <dt-bindings/clock/qcom,gcc-sdm845.h>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/soc/qcom,rpmh-rsc.h>
>>
>> / {
>> interrupt-parent = <&intc>;
>> @@ -984,6 +985,24 @@
>> #mbox-cells = <1>;
>> };
>>
>> + apps_rsc: rsc at 179c0000 {
>> + label = "apps_rsc";
>> + compatible = "qcom,rpmh-rsc";
>> + reg = <0x179c0000 0x10000>,
>> + <0x179d0000 0x10000>,
>> + <0x179e0000 0x10000>;
>> + reg-names = "drv-0", "drv-1", "drv-2";
>> + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
>> + qcom,tcs-offset = <0xd00>;
>> + qcom,drv-id = <2>;
>> + qcom,tcs-config = <SLEEP_TCS 3>,
>> + <WAKE_TCS 3>,
>> + <ACTIVE_TCS 2>,
>> + <CONTROL_TCS 1>;
>
> Sorry, my example had this incorrect order and I just noticed this. We
> will need to fix the example as well.
>
> The first TCS should be ACTIVE_TCS, then followed by SLEEP_TCS and
> WAKE_TCS. This order is important and should match what is set in the
> firmware.
>
> qcom,tcs-config = <ACTIVE_TCS 2>,
> <SLEEP_TCS 3>,
> <WAKE_TCS 3>,
> <CONTROL_TCS 1>;
>
> While the above configuration would work for now, it would fail, when we
> enable system low power modes, which would use TCSes 2-7 for sleep and
> wake set transitions from the firmware.
Since I'm not expecting lots more feedback, I've gone ahead and sent
v2 with this fix.
-Doug
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: sdm845: Add rpmh-clk node
From: Douglas Anderson @ 2018-06-18 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618215051.156270-1-dianders@chromium.org>
This adds the rpmh-clk node to sdm845 based on the examples in the
bindings.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
NOTE: to apply this patch cleanly, apply it atop:
arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes
https://patchwork.kernel.org/patch/10462691/
Changes in v2: None
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 43a182fb42c9..00722b533a92 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -6,6 +6,7 @@
*/
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
+#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
@@ -1001,6 +1002,11 @@
<SLEEP_TCS 3>,
<WAKE_TCS 3>,
<CONTROL_TCS 1>;
+
+ rpmhcc: clock-controller {
+ compatible = "qcom,sdm845-rpmh-clk";
+ #clock-cells = <1>;
+ };
};
intc: interrupt-controller at 17a00000 {
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: sdm845: Add rpmh-rsc node
From: Douglas Anderson @ 2018-06-18 21:50 UTC (permalink / raw)
To: linux-arm-kernel
This adds the rpmh-rsc node to sdm845 based on the examples in the
bindings.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2:
- Fixed ordering of tcs-config as per Lina.
arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cd308b84bed7..43a182fb42c9 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/soc/qcom,rpmh-rsc.h>
/ {
interrupt-parent = <&intc>;
@@ -984,6 +985,24 @@
#mbox-cells = <1>;
};
+ apps_rsc: rsc at 179c0000 {
+ label = "apps_rsc";
+ compatible = "qcom,rpmh-rsc";
+ reg = <0x179c0000 0x10000>,
+ <0x179d0000 0x10000>,
+ <0x179e0000 0x10000>;
+ reg-names = "drv-0", "drv-1", "drv-2";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ qcom,tcs-offset = <0xd00>;
+ qcom,drv-id = <2>;
+ qcom,tcs-config = <ACTIVE_TCS 2>,
+ <SLEEP_TCS 3>,
+ <WAKE_TCS 3>,
+ <CONTROL_TCS 1>;
+ };
+
intc: interrupt-controller at 17a00000 {
compatible = "arm,gic-v3";
#address-cells = <1>;
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: sdm845: Add rpmh-rsc node
From: Lina Iyer @ 2018-06-18 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618205616.102750-1-dianders@chromium.org>
On Mon, Jun 18 2018 at 14:56 -0600, Douglas Anderson wrote:
>This adds the rpmh-rsc node to sdm845 based on the examples in the
>bindings.
>
>Signed-off-by: Douglas Anderson <dianders@chromium.org>
>---
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
>diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>index cd308b84bed7..19b006293d3b 100644
>--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>@@ -7,6 +7,7 @@
>
> #include <dt-bindings/clock/qcom,gcc-sdm845.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
>+#include <dt-bindings/soc/qcom,rpmh-rsc.h>
>
> / {
> interrupt-parent = <&intc>;
>@@ -984,6 +985,24 @@
> #mbox-cells = <1>;
> };
>
>+ apps_rsc: rsc at 179c0000 {
>+ label = "apps_rsc";
>+ compatible = "qcom,rpmh-rsc";
>+ reg = <0x179c0000 0x10000>,
>+ <0x179d0000 0x10000>,
>+ <0x179e0000 0x10000>;
>+ reg-names = "drv-0", "drv-1", "drv-2";
>+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
>+ qcom,tcs-offset = <0xd00>;
>+ qcom,drv-id = <2>;
>+ qcom,tcs-config = <SLEEP_TCS 3>,
>+ <WAKE_TCS 3>,
>+ <ACTIVE_TCS 2>,
>+ <CONTROL_TCS 1>;
Sorry, my example had this incorrect order and I just noticed this. We
will need to fix the example as well.
The first TCS should be ACTIVE_TCS, then followed by SLEEP_TCS and
WAKE_TCS. This order is important and should match what is set in the
firmware.
qcom,tcs-config = <ACTIVE_TCS 2>,
<SLEEP_TCS 3>,
<WAKE_TCS 3>,
<CONTROL_TCS 1>;
While the above configuration would work for now, it would fail, when we
enable system low power modes, which would use TCSes 2-7 for sleep and
wake set transitions from the firmware.
Thanks,
Lina
>+ };
>+
> intc: interrupt-controller at 17a00000 {
> compatible = "arm,gic-v3";
> #address-cells = <1>;
>--
>2.18.0.rc1.244.gcf134e6275-goog
>
^ permalink raw reply
* Dynamic ftrace self test broken on ARM
From: Stefan Agner @ 2018-06-18 21:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On a ARM (i.MX 7) I noticed today that the kernel crashes after dynamic
ftrace self test. I tried v4.18-rc1 first, but it seems that at least
also v4.17 is affected.
Booting Linux on physical CPU 0x0
Linux version 4.17.0 (ags at trochilidae) (gcc version 7.2.1 20171011
(Linaro GCC 7.2-2017.11)) #564 SMP Mon Jun 18 23:00:48 CEST 2018
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
CPU: div instructions available: patching division code
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt: Machine model: Toradex Colibri iMX7D 1GB (eMMC) on Colibri
Evaluation Board V3
bootconsole [earlycon0] enabled
Memory policy: Data cache writealloc
Ignoring RAM at 0xb0000000-0xc0000000
Consider using a HIGHMEM enabled kernel.
cma: Reserved 256 MiB at 0xa0000000
psci: probing for conduit method from DT.
psci: Using PSCI v0.1 Function IDs from DT
percpu: Embedded 17 pages/cpu @(ptrval) s39308 r8192 d22132 u69632
Built 1 zonelists, mobility grouping on. Total pages: 195072
Kernel command line: earlyprintk root=/dev/mmcblk0p2 rootfstype=ext4
rootwait ip=off console=tty1 console=ttymxc0,115200n8 ${extraargs}
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 501152K/786432K available (9216K kernel code, 682K rwdata, 3016K
rodata, 1024K init, 397K bss, 23136K reserved, 262144K cma-reserved)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xf0800000 - 0xff800000 ( 240 MB)
lowmem : 0xc0000000 - 0xf0000000 ( 768 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0x(ptrval) - 0x(ptrval) (10208 kB)
.init : 0x(ptrval) - 0x(ptrval) (1024 kB)
.data : 0x(ptrval) - 0x(ptrval) ( 683 kB)
.bss : 0x(ptrval) - 0x(ptrval) ( 398 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
ftrace: allocating 32657 entries in 96 pages
Hierarchical RCU implementation.
RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
GIC: Using split EOI/Deactivate mode
arch_timer: cp15 timer(s) running at 8.00MHz (phys).
clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles:
0x1d854df40, max_idle_ns: 440795202120 ns
sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every
2199023255500ns
Switching to timer-based delay loop, resolution 125ns
Switching to timer-based delay loop, resolution 41ns
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
89478484971ns
clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 79635851949 ns
Console: colour dummy device 80x30
console [tty1] enabled
Calibrating delay loop (skipped), value calculated using timer
frequency.. 48.00 BogoMIPS (lpj=240000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: update cpu_capacity 1024
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x80100000 - 0x80100060
Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
CPU1: update cpu_capacity 1024
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
smp: Brought up 1 node, 2 CPUs
SMP: Total of 2 processors activated (96.00 BogoMIPS).
CPU: All CPU(s) started in HYP mode.
CPU: Virtualization extensions available.
devtmpfs: initialized
random: get_random_u32 called from bucket_table_alloc+0x84/0x19c with
crng_init=0
VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 19112604462750000 ns
futex hash table entries: 512 (order: 3, 32768 bytes)
Running postponed tracer tests:
Testing tracer function: PASSED
Testing dynamic ftrace: PASSED
Testing dynamic ftrace ops #1:
(1 0 1 0 0)
(1 1 2 0 0)
(2 1 3 0 93620)
(2 2 4 0 93807) PASSED
Testing dynamic ftrace ops #2:
(1 0 1 96630 0)
(1 1 2 96804 0)
(2 1 3 1 342)
(2 2 4 121 462) PASSED
Testing ftrace recursion: PASSED
Testing ftrace recursion safe: PASSED
Testing ftrace regs: PASSED
Testing tracer nop: PASSED
Testing tracer function_graph: PASSED
pinctrl core: initialized pinctrl subsystem
Unable to handle kernel paging request at virtual address c0ca14e4
pgd = (ptrval)
[c0ca14e4] *pgd=80c1940e(bad)
Internal error: Oops: 80d [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.17.0 #564
Hardware name: Freescale i.MX7 Dual (Device Tree)
PC is at skb_init+0x50/0x7c
LR is at kmem_cache_create_usercopy+0x10c/0x320
pc : [<c0e63b80>] lr : [<c023bd5c>] psr: 60000013
sp : dc11be98 ip : dc11be58 fp : dc11bebc
r10: c0e006f0 r9 : c0e82820 r8 : c0faa8c0
r7 : c0e63a10 r6 : 00000000 r5 : 00000000 r4 : c0ca14e4
r3 : c0eb72c8 r2 : 00000000 r1 : 1ea8b000 r0 : dc0eef00
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 8000406a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
Stack: (0xdc11be98 to 0xdc11c000)
be80: 00000018
00000030
bea0: 00000000 c07fda4c 00000000 ffffe000 dc11bedc dc11bec0 c0e63a38
c0e63b3c
bec0: c0e5d488 c0170c64 c0fa7140 c0fa7140 dc11bf44 dc11bee0 c0103080
c0e63a1c
bee0: c0145d74 c0e006fc c0bf3c00 c0bf3ca4 c0bf3cf0 c0c03b98 00000000
c0bf3c7c
bf00: 00000001 00000001 c0bf6c04 c0cf0b68 dffffc66 00000000 00000000
c0fa7140
bf20: c0e82844 00000002 c0fa7140 c0eb6264 00000002 c0faa8c0 dc11bf94
dc11bf48
bf40: c0e011d8 c0103038 00000001 00000001 00000000 c0e006f0 00000000
c0f09fc0
bf60: c0cf0b68 000000dc c0989c58 00000000 c0989c58 00000000 00000000
00000000
bf80: 00000000 00000000 dc11bfac dc11bf98 c0989c70 c0e00f74 00000000
c0989c58
bfa0: 00000000 dc11bfb0 c01010e8 c0989c64 00000000 00000000 00000000
00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000
00000000
[<c0e63b80>] (skb_init) from [<c0e63a38>] (sock_init+0x28/0xc8)
[<c0e63a38>] (sock_init) from [<c0103080>] (do_one_initcall+0x54/0x1e8)
[<c0103080>] (do_one_initcall) from [<c0e011d8>]
(kernel_init_freeable+0x270/0x308)
[<c0e011d8>] (kernel_init_freeable) from [<c0989c70>]
(kernel_init+0x18/0x124)
[<c0989c70>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
Exception stack(0xdc11bfb0 to 0xdc11bff8)
bfa0: 00000000 00000000 00000000
00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: e58d3000 e3a010b8 e3a03a42 ebcf6033 (e5840000)
---[ end trace fff84001ba23c9c9 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 2.292924]
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.17.0 #564
Hardware name: Freescale i.MX7 Dual (Device Tree)
[<c01128a4>] (unwind_backtrace) from [<c010d868>] (show_stack+0x20/0x24)
[<c010d868>] (show_stack) from [<c0975590>] (dump_stack+0x90/0xa4)
[<c0975590>] (dump_stack) from [<c0110608>] (handle_IPI+0x2dc/0x2fc)
[<c0110608>] (handle_IPI) from [<c010233c>] (gic_handle_irq+0x9c/0xa0)
[<c010233c>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0x6c/0x90)
Exception stack(0xdc14df18 to 0xdc14df60)
df00: 00000000
00000324
df20: df957420 c011c4c0 ffffe000 c0f05d28 c0f05d6c 00000002 00000000
c0f05d80
df40: 00000000 dc14df74 dc14df78 dc14df68 c0109938 c010993c 60000013
ffffffff
[<c0101a0c>] (__irq_svc) from [<c010993c>] (arch_cpu_idle+0x48/0x4c)
[<c010993c>] (arch_cpu_idle) from [<c098f81c>]
(default_idle_call+0x30/0x3c)
[<c098f81c>] (default_idle_call) from [<c01566a4>] (do_idle+0x1bc/0x284)
[<c01566a4>] (do_idle) from [<c0156a18>] (cpu_startup_entry+0x28/0x30)
[<c0156a18>] (cpu_startup_entry) from [<c01100b0>]
(secondary_start_kernel+0x158/0x164)
[<c01100b0>] (secondary_start_kernel) from [<8010274c>] (0x8010274c)
---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
]---
I tested with imx_v6_v7_defconfig and enabled the following options:
CONFIG_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_FTRACE_MCOUNT_RECORD=y
CONFIG_FTRACE_SELFTEST=y
CONFIG_FTRACE_STARTUP_TEST=y
I guess startup test should leave the kernel unencumbered?
--
Stefan
^ permalink raw reply
* [PATCH 2/2] arm64: dts: sdm845: Add rpmh-clk node
From: Douglas Anderson @ 2018-06-18 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618205616.102750-1-dianders@chromium.org>
This adds the rpmh-clk node to sdm845 based on the examples in the
bindings.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
NOTE: to apply this patch cleanly, apply it atop:
arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes
https://patchwork.kernel.org/patch/10462691/
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 19b006293d3b..c61ae815a697 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -6,6 +6,7 @@
*/
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
+#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
@@ -1001,6 +1002,11 @@
<WAKE_TCS 3>,
<ACTIVE_TCS 2>,
<CONTROL_TCS 1>;
+
+ rpmhcc: clock-controller {
+ compatible = "qcom,sdm845-rpmh-clk";
+ #clock-cells = <1>;
+ };
};
intc: interrupt-controller at 17a00000 {
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: sdm845: Add rpmh-rsc node
From: Douglas Anderson @ 2018-06-18 20:56 UTC (permalink / raw)
To: linux-arm-kernel
This adds the rpmh-rsc node to sdm845 based on the examples in the
bindings.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cd308b84bed7..19b006293d3b 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/soc/qcom,rpmh-rsc.h>
/ {
interrupt-parent = <&intc>;
@@ -984,6 +985,24 @@
#mbox-cells = <1>;
};
+ apps_rsc: rsc at 179c0000 {
+ label = "apps_rsc";
+ compatible = "qcom,rpmh-rsc";
+ reg = <0x179c0000 0x10000>,
+ <0x179d0000 0x10000>,
+ <0x179e0000 0x10000>;
+ reg-names = "drv-0", "drv-1", "drv-2";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ qcom,tcs-offset = <0xd00>;
+ qcom,drv-id = <2>;
+ qcom,tcs-config = <SLEEP_TCS 3>,
+ <WAKE_TCS 3>,
+ <ACTIVE_TCS 2>,
+ <CONTROL_TCS 1>;
+ };
+
intc: interrupt-controller at 17a00000 {
compatible = "arm,gic-v3";
#address-cells = <1>;
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v4 16/19] media: platform: Add Sunxi-Cedrus VPU decoder driver
From: kbuild test robot @ 2018-06-18 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618145843.14631-17-paul.kocialkowski@bootlin.com>
Hi Paul,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.18-rc1 next-20180618]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Paul-Kocialkowski/Sunxi-Cedrus-driver-for-the-Allwinner-Video-Engine-using-media-requests/20180619-020757
base: git://linuxtv.org/media_tree.git master
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
drivers/media/platform/sunxi/cedrus/cedrus_video.c: In function 'cedrus_stop_streaming':
>> drivers/media/platform/sunxi/cedrus/cedrus_video.c:434:3: error: implicit declaration of function 'v4l2_ctrl_request_complete'; did you mean 'v4l2_ctrl_replace'? [-Werror=implicit-function-declaration]
v4l2_ctrl_request_complete(vbuf->vb2_buf.req_obj.req,
^~~~~~~~~~~~~~~~~~~~~~~~~~
v4l2_ctrl_replace
>> drivers/media/platform/sunxi/cedrus/cedrus_video.c:434:43: error: 'struct vb2_buffer' has no member named 'req_obj'
v4l2_ctrl_request_complete(vbuf->vb2_buf.req_obj.req,
^
drivers/media/platform/sunxi/cedrus/cedrus_video.c: In function 'cedrus_buf_request_complete':
drivers/media/platform/sunxi/cedrus/cedrus_video.c:452:31: error: 'struct vb2_buffer' has no member named 'req_obj'
v4l2_ctrl_request_complete(vb->req_obj.req, &ctx->hdl);
^~
drivers/media/platform/sunxi/cedrus/cedrus_video.c: At top level:
>> drivers/media/platform/sunxi/cedrus/cedrus_video.c:461:3: error: 'struct vb2_ops' has no member named 'buf_request_complete'
.buf_request_complete = cedrus_buf_request_complete,
^~~~~~~~~~~~~~~~~~~~
>> drivers/media/platform/sunxi/cedrus/cedrus_video.c:461:26: warning: excess elements in struct initializer
.buf_request_complete = cedrus_buf_request_complete,
^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/media/platform/sunxi/cedrus/cedrus_video.c:461:26: note: (near initialization for 'cedrus_qops')
cc1: some warnings being treated as errors
--
drivers/media/platform/sunxi/cedrus/cedrus_dec.c: In function 'cedrus_device_run':
>> drivers/media/platform/sunxi/cedrus/cedrus_dec.c:91:28: error: 'struct vb2_buffer' has no member named 'req_obj'
src_req = run.src->vb2_buf.req_obj.req;
^
>> drivers/media/platform/sunxi/cedrus/cedrus_dec.c:94:3: error: implicit declaration of function 'v4l2_ctrl_request_setup'; did you mean 'v4l2_ctrl_handler_setup'? [-Werror=implicit-function-declaration]
v4l2_ctrl_request_setup(src_req, &ctx->hdl);
^~~~~~~~~~~~~~~~~~~~~~~
v4l2_ctrl_handler_setup
>> drivers/media/platform/sunxi/cedrus/cedrus_dec.c:123:3: error: implicit declaration of function 'v4l2_ctrl_request_complete'; did you mean 'v4l2_ctrl_replace'? [-Werror=implicit-function-declaration]
v4l2_ctrl_request_complete(src_req, &ctx->hdl);
^~~~~~~~~~~~~~~~~~~~~~~~~~
v4l2_ctrl_replace
cc1: some warnings being treated as errors
vim +434 drivers/media/platform/sunxi/cedrus/cedrus_video.c
413
414 static void cedrus_stop_streaming(struct vb2_queue *q)
415 {
416 struct cedrus_ctx *ctx = vb2_get_drv_priv(q);
417 struct vb2_v4l2_buffer *vbuf;
418 unsigned long flags;
419
420 flush_scheduled_work();
421 for (;;) {
422 spin_lock_irqsave(&ctx->dev->irq_lock, flags);
423
424 if (V4L2_TYPE_IS_OUTPUT(q->type))
425 vbuf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
426 else
427 vbuf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
428
429 spin_unlock_irqrestore(&ctx->dev->irq_lock, flags);
430
431 if (vbuf == NULL)
432 return;
433
> 434 v4l2_ctrl_request_complete(vbuf->vb2_buf.req_obj.req,
435 &ctx->hdl);
436 v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
437 }
438 }
439
440 static void cedrus_buf_queue(struct vb2_buffer *vb)
441 {
442 struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
443 struct cedrus_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
444
445 v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vbuf);
446 }
447
448 static void cedrus_buf_request_complete(struct vb2_buffer *vb)
449 {
450 struct cedrus_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
451
> 452 v4l2_ctrl_request_complete(vb->req_obj.req, &ctx->hdl);
453 }
454
455 static struct vb2_ops cedrus_qops = {
456 .queue_setup = cedrus_queue_setup,
457 .buf_prepare = cedrus_buf_prepare,
458 .buf_init = cedrus_buf_init,
459 .buf_cleanup = cedrus_buf_cleanup,
460 .buf_queue = cedrus_buf_queue,
> 461 .buf_request_complete = cedrus_buf_request_complete,
462 .stop_streaming = cedrus_stop_streaming,
463 .wait_prepare = vb2_ops_wait_prepare,
464 .wait_finish = vb2_ops_wait_finish,
465 };
466
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 65280 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180619/c08b77c7/attachment-0001.gz>
^ permalink raw reply
* [PATCH v3 06/14] mtd: rawnand: marvell: remove the dmaengine compat need
From: Robert Jarzmik @ 2018-06-18 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3a2a8951-f380-af99-bf97-6ff722404410@zonque.org>
Daniel Mack <daniel@zonque.org> writes:
> On Sunday, June 17, 2018 07:02 PM, Robert Jarzmik wrote:
>> As the pxa architecture switched towards the dmaengine slave map, the
>> old compatibility mechanism to acquire the dma requestor line number and
>> priority are not needed anymore.
>>
>> This patch simplifies the dma resource acquisition, using the more
>> generic function dma_request_slave_channel().
>>
>> Signed-off-by: Signed-off-by: Daniel Mack <daniel@zonque.org>
>
> Something went wrong here, but you can simply fix that when applying the series
> :)
Indeed, fixed before applying to the pxa/for-next tree.
--
Robert
^ permalink raw reply
* [PATCH 1/2] arm64: dts: exynos: Remove leading 0x from unit addresses in Exynos5433
From: Krzysztof Kozlowski @ 2018-06-18 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6755acb72649a712bd16cee4cab92f1aa63b70b9.camel@perches.com>
On 18 June 2018 at 19:57, Joe Perches <joe@perches.com> wrote:
> On Mon, 2018-06-18 at 19:42 +0200, Krzysztof Kozlowski wrote:
>> Remove leading 0x from recently introduced unit addresses to fix DTC
>> warnings:
>>
>> Warning (unit_address_format): /soc/sysmmu at 0x15040000: unit name should not have leading "0x"
> []
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> []
>> @@ -1171,7 +1171,7 @@
>> power-domains = <&pd_gscl>;
>> };
>>
>> - sysmmu_scaler_0: sysmmu at 0x15040000 {
>> + sysmmu_scaler_0: sysmmu at 15040000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x15040000 0x1000>;
>> interrupts = <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>;
>> @@ -1182,7 +1182,7 @@
>> power-domains = <&pd_mscl>;
>> };
>>
>> - sysmmu_scaler_1: sysmmu at 0x15050000 {
>> + sysmmu_scaler_1: sysmmu at 15050000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x15050000 0x1000>;
>> interrupts = <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>;
>
> Presumably these 3 other entries too?
>
> $ git grep -P "\b\w+:\s+\w+ at 0x" -- "*.dt*"
> arch/arc/boot/dts/abilis_tb10x.dtsi: spi0: spi at 0xFE010000 {
> arch/arc/boot/dts/abilis_tb10x.dtsi: spi1: spi at 0xFE011000 {
> arch/arc/boot/dts/vdk_axs10x_mb.dtsi: uio_ev: uio at 0xD0000000 {
True. That's an "arc" but I can fix it as well with your reported-by.
Best regards,
Krzysztof
^ permalink raw reply
* [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
From: Icenowy Zheng @ 2018-06-18 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15787507.kzqBcLUy0z@jernej-laptop>
? 2018-06-18?? 16:43 +0200?Jernej ?krabec???
> Dne ponedeljek, 18. junij 2018 ob 14:58:02 CEST je Jagan Teki
> napisal(a):
> > On Thu, Jun 14, 2018 at 10:59 PM, Jernej ?krabec
> >
> > <jernej.skrabec@siol.net> wrote:
> > > Dne ?etrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki
> > > napisal(a):
> > > > On Thu, Jun 14, 2018 at 8:04 PM, Jernej ?krabec <jernej.skrabec
> > > > @siol.net>
> > >
> > > wrote:
> > > > > Dne ?etrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki
> > > > > napisal(a):
> > > > > > On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec
> > > > > > <jernej.skrabec@siol.net>
> > > > >
> > > > > wrote:
> > > > > > > This series adds support for R40 HDMI pipeline. It is a
> > > > > > > bit special
> > > > > > > than other already supported pipelines because it has
> > > > > > > additional
> > > > > > > unit
> > > > > > > called TCON TOP responsible for relationship
> > > > > > > configuration between
> > > > > > > mixers, TCONs and HDMI. Additionally, it has additional
> > > > > > > gates for
> > > > > > > DSI
> > > > > > > and TV TCONs, TV encoder clock settings and pin muxing
> > > > > > > between LCD
> > > > > > > and TV encoders.
> > > > > > >
> > > > > > > However, it seems that TCON TOP will become a norm, since
> > > > > > > newer
> > > > > > > Allwinner SoCs like H6 also have this unit.
> > > > > > >
> > > > > > > I tested different possible configurations:
> > > > > > > - mixer0 <> TCON-TV0 <> HDMI
> > > > > > > - mixer0 <> TCON-TV1 <> HDMI
> > > > > > > - mixer1 <> TCON-TV0 <> HDMI
> > > > > > > - mixer1 <> TCON-TV1 <> HDMI
> > > > > > >
> > > > > > > Please review.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Jernej
> > > > > > >
> > > > > > > Changes from v1:
> > > > > > > - Split DT bindings patch and updated description
> > > > > > > - Split HDMI PHY patch
> > > > > > > - Move header file from TCON TOP patch to dt bindings
> > > > > > > patch
> > > > > > > - Added Rob reviewed-by tag
> > > > > > > - Used clk_hw_register_gate() instead of custom gate
> > > > > > > registration
> > > > > > > code
> > > > > > > - Reworked TCON TOP to be part of of-graph. Because of
> > > > > > > that, a lot
> > > > > > > of
> > > > > > >
> > > > > > > new patches were added.
> > > > > > >
> > > > > > > - Droped mixer index quirk patch
> > > > > > > - Reworked TCON support for TCON TOP
> > > > > > > - Updated commit messages
> > > > > > >
> > > > > > > Jernej Skrabec (27):
> > > > > > > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> > > > > > > clk: sunxi-ng: r40: Allow setting parent rate to
> > > > > > > display related
> > > > > > >
> > > > > > > clocks
> > > > > > >
> > > > > > > clk: sunxi-ng: r40: Export video PLLs
> > > > > > > dt-bindings: display: sunxi-drm: Add TCON TOP
> > > > > > > description
> > > > > > > drm/sun4i: Add TCON TOP driver
> > > > > > > drm/sun4i: Fix releasing node when enumerating enpoints
> > > > > > > drm/sun4i: Split out code for enumerating endpoints in
> > > > > > > output port
> > > > > > > drm/sun4i: Add support for traversing graph with TCON
> > > > > > > TOP
> > > > > > > drm/sun4i: Don't skip TCONs if they don't have channel
> > > > > > > 0
> > > > > > > dt-bindings: display: sun4i-drm: Add R40 TV TCON
> > > > > > > description
> > > > > > > drm/sun4i: tcon: Add support for tcon-top gate
> > > > > > > drm/sun4i: tcon: Generalize engine search algorithm
> > > > > > > drm/sun4i: Don't check for LVDS and RGB when TCON has
> > > > > > > only ch1
> > > > > > > drm/sun4i: Don't check for panel or bridge on TV TCONs
> > > > > > > drm/sun4i: Add support for R40 TV TCON
> > > > > > > dt-bindings: display: sun4i-drm: Add R40 mixer
> > > > > > > compatibles
> > > > > > > drm/sun4i: Add support for R40 mixers
> > > > > > > dt-bindings: display: sun4i-drm: Add description of A64
> > > > > > > HDMI PHY
> > > > > > > drm/sun4i: Enable DW HDMI PHY clock
> > > > > > > drm/sun4i: Don't change clock bits in DW HDMI PHY
> > > > > > > driver
> > > > > > > drm/sun4i: DW HDMI PHY: Add support for second PLL
> > > > > > > drm/sun4i: Add support for second clock parent to DW
> > > > > > > HDMI PHY clk
> > > > > > >
> > > > > > > driver
> > > > > > >
> > > > > > > drm/sun4i: Add support for A64 HDMI PHY
> > > > > > > drm: of: Export drm_crtc_port_mask()
> > > > > > > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> > > > > > > ARM: dts: sun8i: r40: Add HDMI pipeline
> > > > > > > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2
> > > > > > > Ultra
> > > > > >
> > > > > > Tested whole series on top of linux-next.
> > > > > >
> > > > > > Tested-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > >
> > > > > Thanks!
> > > >
> > > > I've V40 board, which is same as R40. I'm able to detect the
> > > > HDMI but
> > > > seems edid not detecting properly.
> > > >
> > > > [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer
> > > > (ops
> > > > 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound
> > > > 1200000.mixer
> > > > (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
> > > > 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm
> > > > display-engine:
> > > > bound 1c73000.lcd-controller (ops 0xc0747a28)
> > > > [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX
> > > > controller
> > > > v1.32a with HDCP (sun8i_dw_hdmi_phy)
> > > > [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered
> > > > DesignWare HDMI
> > > > I2C bus driver
> > > > [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi
> > > > (ops
> > > > 0xc074a298) [ 1.078484] [drm] Supports vblank timestamp
> > > > caching Rev 2
> > > > (21.10.2013). [ 1.085098] [drm] No driver support for vblank
> > > > timestamp query. [ 1.091055] [drm] Cannot find any crtc or
> > > > sizes
> > > > [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> > > > display-engine on minor 0
> > >
> > > This seems like DT issue. Can you post somewhere your V40 DTSI
> > > (if it is
> > > different to R40) and board DTS?
> >
> > same dtsi shared between r40 and v40, here is board dts support for
> > HDMI[1]
> >
> > [1] https://paste.ubuntu.com/p/wqVz38BHrM/
>
> This patch looks like exactly the same as mine for BananaPi M2U, so
> there
> should be no issues.
As I know, M2B is designed to be compatible with M2U, so most things
should be the same. The stock firmware even use the same images for
both M2U and M2B.
>
> What about VCC-HDMI? Is powered? Can you measure it to check?
>
> Best regards,
> Jernej
>
>
>
^ permalink raw reply
* [U-Boot] [PATCH 0/4] ARM: Provide workaround setup bits for CVE-2017-5715 (A8/A15)
From: Tom Rini @ 2018-06-18 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-1-nm@ti.com>
On Tue, Jun 12, 2018 at 03:24:07PM -0500, Nishanth Menon wrote:
> Hi,
>
> This is a follow on from https://marc.info/?l=u-boot&m=151691688828176&w=2 (RFC)
>
> NOTE:
> * As per ARM recommendations[2], and discussions in list[1] ARM
> Cortex-A9/12/17 do not need additional steps in u-boot to enable the
> OS level workarounds.
> * This itself is'nt a complete solution and is based on recommendation
> This from Arm[2] for variant 2 CVE-2017-5715 -> Kernel changes can be seen on
> linux next (next-20180612) or on linux master (upcoming v4.18-rc1 tag).
> * I think it is necessary on older SoCs without firmware support
> (such as older OMAPs and AM*) to have kernel support mirroring what we do in
> u-boot to support additional cores AND/OR low power states where contexts are
> lost (assuming ACR states are'nt saved). just my 2 cents.
>
> Few of the tests (with linux next-20180612):
> AM571-IDK: https://pastebin.ubuntu.com/p/sr5X6sN3Tr/ (single core A15)
> OMAP5-uEVM: https://pastebin.ubuntu.com/p/9yDM22bJ6n/ (dual core A15)
> OMAP3-beagle-xm: https://pastebin.ubuntu.com/p/9DfDkpyxym/ (Single A8)
> AM335x-Beaglebone-black: https://pastebin.ubuntu.com/p/DczT9jPMwb/ (Single A8)
>
> Nishanth Menon (4):
> ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
> CVE-2017-5715
> ARM: Introduce ability to enable invalidate of BTB with ICIALLU on
> Cortex-A15 for CVE-2017-5715
> ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of
> BTB) to facilitate CVE_2017-5715 WA in OS
> ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for
> CVE-2017-5715
>
> arch/arm/Kconfig | 9 +++++++++
> arch/arm/cpu/armv7/start.S | 15 +++++++++++++--
> arch/arm/mach-omap2/Kconfig | 3 +++
> 3 files changed, 25 insertions(+), 2 deletions(-)
>
> [1] https://marc.info/?t=151639906500002&r=1&w=2
> [2] https://developer.arm.com/support/security-update
> [3] https://marc.info/?t=151543790400007&r=1&w=2 and the latest in:
> https://marc.info/?l=linux-arm-kernel&m=151689379521082&w=2
> [4]
> https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6
> https://www.op-tee.org/security-advisories/
> https://www.linaro.org/blog/meltdown-spectre/
This series of changes for U-Boot, if I can briefly summarize the
feedback as I understand it, is that yes, this is correct and is a part
of what is required to work around the issues, but only covers as much
of the system as U-Boot can cover leaving other parts of the software
stack (still) in need of fixes. Yes? If so, is there anything else
that should be done before in U-Boot we grab these changes? Would any
of the knowledgeable but not usually U-Boot folks on CC feel comfortable
adding an ack/reviewed-by to the series? Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180618/fbdc1526/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] arm64: dts: exynos: Remove unneeded DSI and DECON address/size cells in Exynos5433
From: Krzysztof Kozlowski @ 2018-06-18 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618174216.24801-2-krzk@kernel.org>
On Mon, Jun 18, 2018 at 07:42:16PM +0200, Krzysztof Kozlowski wrote:
> The decon, decon_tv and dsi nodes have only one child port so
> address/size mappings are not necessary. This fixes DTC warnings like:
>
> Warning (graph_child_address): /soc/decon at 13800000/ports:
> graph node has single child node 'port at 0', #address-cells/#size-cells are not necessary
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 +-----
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 12 ++----------
> 2 files changed, 3 insertions(+), 15 deletions(-)
The patch 1/2 should not have any impact but this one could have and I forgot
to mention that it was not tested. If someone could provide testing, it
would be highly appreciated.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: hikey960: Clean up MMC properties and move to proper file
From: Ryan Grachek @ 2018-06-18 18:10 UTC (permalink / raw)
To: linux-arm-kernel
Certain properties should be moved to the board file to reflect
the specific properties of the board, and not the SoC. Move these
properties to proper location and organize properties in both files.
Signed-off-by: Ryan Grachek <ryan@edited.us>
---
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 27 ++++++++++++++++++-----
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 27 +++++------------------
2 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index abc991619c75..1c2a9a5d0477 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -602,20 +602,37 @@
};
&dwmmc1 {
+ bus-width = <0x4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ disable-wp;
+ cd-inverted;
+ cd-gpios = <&gpio25 3 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd_pmx_func
+ &sd_clk_cfg_func
+ &sd_cfg_func>;
vmmc-supply = <&ldo16>;
vqmmc-supply = <&ldo9>;
status = "okay";
};
&dwmmc2 { /* WIFI */
- broken-cd;
- /* WL_EN */
- vmmc-supply = <&wlan_en>;
+ bus-width = <0x4>;
non-removable;
+ broken-cd;
+ cap-sd-highspeed;
cap-power-off-card;
keep-power-in-suspend;
- #address-cells = <0x1>;
- #size-cells = <0x0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdio_pmx_func
+ &sdio_clk_cfg_func
+ &sdio_cfg_func>;
+ /* WL_EN */
+ vmmc-supply = <&wlan_en>;
status = "ok";
wlcore: wlcore at 2 {
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 74c0509f99e9..fe4c9f321b70 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -1114,15 +1114,10 @@
/* SD */
dwmmc1: dwmmc1 at ff37f000 {
- #address-cells = <1>;
- #size-cells = <0>;
- cd-inverted;
compatible = "hisilicon,hi3660-dw-mshc";
- bus-width = <0x4>;
- disable-wp;
- cap-sd-highspeed;
- card-detect-delay = <200>;
reg = <0x0 0xff37f000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&crg_ctrl HI3660_CLK_GATE_SD>,
<&crg_ctrl HI3660_HCLK_GATE_SD>;
@@ -1130,16 +1125,8 @@
clock-frequency = <3200000>;
resets = <&crg_rst 0x94 18>;
reset-names = "reset";
- cd-gpios = <&gpio25 3 0>;
hisilicon,peripheral-syscon = <&sctrl>;
- pinctrl-names = "default";
- pinctrl-0 = <&sd_pmx_func
- &sd_clk_cfg_func
- &sd_cfg_func>;
- sd-uhs-sdr12;
- sd-uhs-sdr25;
- sd-uhs-sdr50;
- sd-uhs-sdr104;
+ card-detect-delay = <200>;
status = "disabled";
};
@@ -1147,6 +1134,8 @@
dwmmc2: dwmmc2 at ff3ff000 {
compatible = "hisilicon,hi3660-dw-mshc";
reg = <0x0 0xff3ff000 0x0 0x1000>;
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&crg_ctrl HI3660_CLK_GATE_SDIO0>,
<&crg_ctrl HI3660_HCLK_GATE_SDIO0>;
@@ -1154,12 +1143,6 @@
resets = <&crg_rst 0x94 20>;
reset-names = "reset";
card-detect-delay = <200>;
- cap-sd-highspeed;
- keep-power-in-suspend;
- pinctrl-names = "default";
- pinctrl-0 = <&sdio_pmx_func
- &sdio_clk_cfg_func
- &sdio_cfg_func>;
status = "disabled";
};
--
2.11.0
^ permalink raw reply related
* [PATCH] arm64: dts: hikey960: Remove deprecated MMC properties
From: Ryan Grachek @ 2018-06-18 18:08 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Ryan Grachek <ryan@edited.us>
---
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 1 -
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 --------
2 files changed, 9 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index c706f70ce9f2..abc991619c75 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -611,7 +611,6 @@
broken-cd;
/* WL_EN */
vmmc-supply = <&wlan_en>;
- ti,non-removable;
non-removable;
cap-power-off-card;
keep-power-in-suspend;
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 484b837757f3..74c0509f99e9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -1121,7 +1121,6 @@
bus-width = <0x4>;
disable-wp;
cap-sd-highspeed;
- supports-highspeed;
card-detect-delay = <200>;
reg = <0x0 0xff37f000 0x0 0x1000>;
interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
@@ -1142,12 +1141,6 @@
sd-uhs-sdr50;
sd-uhs-sdr104;
status = "disabled";
-
- slot at 0 {
- reg = <0x0>;
- bus-width = <4>;
- disable-wp;
- };
};
/* SDIO */
@@ -1162,7 +1155,6 @@
reset-names = "reset";
card-detect-delay = <200>;
cap-sd-highspeed;
- supports-highspeed;
keep-power-in-suspend;
pinctrl-names = "default";
pinctrl-0 = <&sdio_pmx_func
--
2.11.0
^ permalink raw reply related
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: Geoff Levand @ 2018-06-18 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5b03f754-3a98-c01d-3e2a-615a8b1ea537@arm.com>
Hi James,
Thanks for all the comments, but my lack of access to an m400 platform, and
my lack of knowledge about the m400 limits what I can comment on and what I
can do.
My motivation for submitting this fix was to enable CONFIG_ACPI_APEI in the
Debian 10 kernel (for the new Cavium ThunderX2 based systems). The Debian
maintainers wanted to either have an upstream kernel fix for this m400 APEI
problem or to disable CONFIG_ACPI_APEI. The later would be unfortunate. It
means users would need to have custom kernels to get APEI support or go
without.
Comments follow.
On 06/18/2018 09:18 AM, James Morse wrote:
> On 15/06/18 18:17, Geoff Levand wrote:
>
> From:
> https://bugzilla.redhat.com/show_bug.cgi?id=1574718
>
> This is tripped by the ghes_probe() call, it finds an error has already occurred
> before ghes code is initialized.
>
> Does this still happen if you compile without CONFIG_PCI? (that is easily half
> the dmesg that has happened before this point).
> Disabling CONFIG_EFIVAR_FS would be interesting too, as that is firmware-code we
> can't fix bugs in.
Sorry, no m400 to test these on, but looking at the code, I would say it doesn't
occur if CONFIG_PCI=n.
> Your argument here is the that the firmware-vendor only build-tested their code,
> and never noticed it notifies a fatal exception on startup. I find this hard to
> believe, especially as these systems don't have EL3.
>
> It's much more likely a driver is causing this, possibly because of bad data in
> the firmware tables. I'd like to quirk the driver, so we can fix the next error
> like this, as opposed to blindly continuing.
That sounds OK, but which driver?
> If it really is firmware, what is it doing that causes this error, and where
> does it run? Disabling APEI is just reacting after the error has occurred, when
> we could prevent it happening.
>
> I can't reproduce this on a Mustang. I assume its the different ACPI tables, not
> the kernel-config.
>From what I understand this is only on the m400, not the Mustang.
>> I just put together this patch to unify things and have a
>> common 'upstream' fix.
>
> Wouldn't passing 'hest_disable' on the cmdline do the same for all kernel versions?
Yes, the current patch essentially just sets hest_disable when an m400 is
detected. The cmdline work-around is what some have been using, but is
not an acceptable solution for the Debian maintainers. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900581
>> On 06/15/2018 04:14 AM, James Morse wrote:
>>> On 13/06/18 19:22, Geoff Levand wrote:
>>>> Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
>>>> a work-around for HPE ProLiant m400 APEI firmware problems.
>>>>
>>>> The work-around disables APEI when CONFIG_ACPI_APEI is set and
>>>> m400 firmware is detected. Without this fixup m400 systems
>>>> experience errors like these on startup:
>>>>
>>>> [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
>>>> [Hardware Error]: event severity: fatal
>>>> [Hardware Error]: Error 0, type: fatal
>>>> [Hardware Error]: section_type: memory error
>>>> [Hardware Error]: error_status: 0x0000000000001300
>>>
>>> "Access to a memory address which is not mapped to any component"
>>>
>>>
>>>> [Hardware Error]: error_type: 10, invalid address
>>>> Kernel panic - not syncing: Fatal hardware error!
>>>
>>> Why is this a problem?
>>>
>>> Surely this is a valid description of an error.
>>
>> The firmware bug causes this failure, not bad hardware.
>
> I'm not talking about bad hardware here. What I think is happening is a software
> bug is causing the CPU to make a bad access, which the RAS mechanism is
> reporting like this because software would never be stupid enough to access an
> address which is not mapped to any component! The RAS stuff believes this must
> be address corruption.
>
> I think this is a linux-driver bug, or a typo in the firmware tables, that cause
> $non_existent_address to be mapped and probed.
>From what I know about it the problem is in the access of the firmware tables,
and that corrupted data is retrieved. But I am not sure, as there are so many
reported m400 firmware problems it is hard to tell what exactly is what.
>>>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>>> index 7b09487ff8fb..3c315c2c7476 100644
>>>> --- a/arch/arm64/kernel/acpi.c
>>>> +++ b/arch/arm64/kernel/acpi.c
>
>>>> +
>>>> + if (!IS_ENABLED(CONFIG_ACPI_APEI) || hest_disable != HEST_ENABLED)
>>>> + return;
>>>> +
>>>> + status = acpi_get_table(ACPI_SIG_HEST, 0, &header);
>>>> +
>>>> + if (ACPI_SUCCESS(status) && !strncmp(header->oem_id, "HPE ", 6) &&
>>>> + !strncmp(header->oem_table_id, "ProLiant", 8) &&
>
>>> You should match the affected range of OEM table revisions too, that way a
>>> firmware upgrade should start working, instead of being permanently disabled
>>> because we think its unlikely.
>>
>> The m400 has reached end of life. No one really expects to see any firmware
>> update. I don't know what the effected OEM table revisions are, and I don't
>> think there is an active platform maintainer who could give that info either.
>>
>> If someone can provide the info. I'll update the fix.
>
> We can start with the version you have. You mention distro's have their own
> fixes, hopefully they can supply the missing range of values.
It seems you are living in a dream world...
>>>> + MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM) {
>>>
>>> How is the CPU implementer relevant?
>>
>> That was just a copy of what other fixes had. Should I remove it?
>
> The conclusion in the rest of this thread was HPE also produces ProLiant boxes
> with a (presumably) identical HEST, but a totally different architecture.
>
> Matching the DMI platform name as well would work round this. (or somewhere only
> arm64 builds, with an appropriate comment in case we move it).
>
>
>>> Nothing arch-specific here. You're adding this to arch/arm64 because
>>> drivers/acpi/apei doesn't have an existing quirks table?
>>
>> There was a fix submitted that had it in drivers/acpi/scan.c, but the
>> ACPI maintainer said he didn't want the fix in the main ACPI code.
>
> Specifically about a HID-hack in the core device enumeration code, as opposed to
> in the driver that claims it.
>
>
>> See:
>>
>> https://lkml.org/lkml/2018/4/19/1020 (ACPI / scan: Fix regression related to X-Gene UARTs)
>
> | 'some X-Gene based platforms (Mustang and M400) with invalid DSDT.'
>
> ... sounds familiar ...
>
> And:
> https://bugzilla.redhat.com/attachment.cgi?id=1144903&action=diff
>
> Fixes a typo in firmware description of the GIC.
>
> Why do we think this is a new kind of firmware bug, and not a repeat of the last
> two? The only difference is this is being caught by the RAS code.
It could very well be.
>> The m400 is an arm64 platform, so it seems most appropriate to
>> have it in arch/arm64/kernel/acpi.c.
>
> We don't keep all drivers under arch/arm64, I'd really like to find the driver
> that is causing this, and quirk it there.
>
> If we have to bolt the hest-stable-door, drivers/acpi/apei/hest.c looks better,
> it at least doesn't have to bodge around hest_disabled not being exposed in a
> compatible way. If the maintainer objects, (as x86 hasn't had to do this yet),
> then we can try drivers/acpi/arm64/hest_quirks.c.
We need to call acpi_fixup_m400_quirks early enough to get hest_disable set
before it is used. To do that from drivers/acpi/ code we would need have
it as arch_initcall, or still call it from acpi_boot_table_init. I think
having it as a static routine and the call in arch/arm64/kernel/acpi.c is
cleaner.
> When only once architecture had to quirk stuff based on the ACPI tables, the
> arch-code was a suitable dumping ground. Now there is more than one, we should
> do things in a way they are useful to both architectures.
As I mentioned in the opening, I don't have access to m400 equipment. There is
little I can do. I could move acpi_fixup_m400_quirks into
drivers/acpi/apei/hest.c and submit that to the ACPI maintainer, but based on
https://lkml.org/lkml/2018/4/19/1020, I don't think it would be accepted.
-Geoff
^ permalink raw reply
* [PATCH 1/2] arm64: dts: exynos: Remove leading 0x from unit addresses in Exynos5433
From: Joe Perches @ 2018-06-18 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618174216.24801-1-krzk@kernel.org>
On Mon, 2018-06-18 at 19:42 +0200, Krzysztof Kozlowski wrote:
> Remove leading 0x from recently introduced unit addresses to fix DTC
> warnings:
>
> Warning (unit_address_format): /soc/sysmmu at 0x15040000: unit name should not have leading "0x"
[]
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
[]
> @@ -1171,7 +1171,7 @@
> power-domains = <&pd_gscl>;
> };
>
> - sysmmu_scaler_0: sysmmu at 0x15040000 {
> + sysmmu_scaler_0: sysmmu at 15040000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x15040000 0x1000>;
> interrupts = <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1182,7 +1182,7 @@
> power-domains = <&pd_mscl>;
> };
>
> - sysmmu_scaler_1: sysmmu at 0x15050000 {
> + sysmmu_scaler_1: sysmmu at 15050000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x15050000 0x1000>;
> interrupts = <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>;
Presumably these 3 other entries too?
$ git grep -P "\b\w+:\s+\w+ at 0x" -- "*.dt*"
arch/arc/boot/dts/abilis_tb10x.dtsi: spi0: spi at 0xFE010000 {
arch/arc/boot/dts/abilis_tb10x.dtsi: spi1: spi at 0xFE011000 {
arch/arc/boot/dts/vdk_axs10x_mb.dtsi: uio_ev: uio at 0xD0000000 {
arch/arm64/boot/dts/exynos/exynos5433.dtsi: sysmmu_scaler_0: sysmmu at 0x15040000 {
arch/arm64/boot/dts/exynos/exynos5433.dtsi: sysmmu_scaler_1: sysmmu at 0x15050000 {
^ permalink raw reply
* [PATCH 2/2] arm64: dts: exynos: Remove unneeded DSI and DECON address/size cells in Exynos5433
From: Krzysztof Kozlowski @ 2018-06-18 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618174216.24801-1-krzk@kernel.org>
The decon, decon_tv and dsi nodes have only one child port so
address/size mappings are not necessary. This fixes DTC warnings like:
Warning (graph_child_address): /soc/decon at 13800000/ports:
graph node has single child node 'port at 0', #address-cells/#size-cells are not necessary
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 +-----
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 12 ++----------
2 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index a1e3194b7483..0a15ee513f5c 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -321,11 +321,7 @@
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port at 0 {
- reg = <0>;
+ port {
tv_to_hdmi: endpoint {
remote-endpoint = <&hdmi_to_tv>;
};
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 3a9b4c4b9c63..e4367fd39120 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -850,11 +850,7 @@
iommu-names = "m0", "m1";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port at 0 {
- reg = <0>;
+ port {
decon_to_mic: endpoint {
remote-endpoint =
<&mic_to_decon>;
@@ -914,11 +910,7 @@
#size-cells = <0>;
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port at 0 {
- reg = <0>;
+ port {
dsi_to_mic: endpoint {
remote-endpoint = <&mic_to_dsi>;
};
--
2.14.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox