* [PATCH v2 09/10] arm64: dts: actions: Add MMC controller support for S700
From: Amit Singh Tomar @ 2020-05-19 18:19 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: devicetree, linux-actions, linux-kernel, linux-arm-kernel,
cristian.ciocaltea
In-Reply-To: <1589912368-480-1-git-send-email-amittomer25@gmail.com>
This commits adds support for MMC controllers present on Actions S700 SoC,
there are 3 MMC controllers in this SoC which can be used for accessing
SD/EMMC/SDIO cards.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since v1:
* Added SoC specific compatibe string.
Changes since RFC:
* No change.
---
arch/arm64/boot/dts/actions/s700.dtsi | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 56f2f84812cb..0d3ff315b00e 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -258,5 +258,38 @@
dma-requests = <44>;
clocks = <&cmu CLK_DMAC>;
};
+
+ mmc0: mmc@e0210000 {
+ compatible = "actions,s700-mmc", "actions,owl-mmc";
+ reg = <0x0 0xe0210000 0x0 0x4000>;
+ interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD0>;
+ resets = <&cmu RESET_SD0>;
+ dmas = <&dma 2>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc1: mmc@e0214000 {
+ compatible = "actions,s700-mmc", "actions,owl-mmc";
+ reg = <0x0 0xe0214000 0x0 0x4000>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD1>;
+ resets = <&cmu RESET_SD1>;
+ dmas = <&dma 3>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc2: mmc@e0218000 {
+ compatible = "actions,s700-mmc", "actions,owl-mmc";
+ reg = <0x0 0xe0218000 0x0 0x4000>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD2>;
+ resets = <&cmu RESET_SD2>;
+ dmas = <&dma 4>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
};
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 10/10] arm64: dts: actions: Add uSD support for Cubieboard7
From: Amit Singh Tomar @ 2020-05-19 18:19 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: devicetree, linux-actions, linux-kernel, linux-arm-kernel,
cristian.ciocaltea
In-Reply-To: <1589912368-480-1-git-send-email-amittomer25@gmail.com>
This commit adds uSD support for Cubieboard7 board based on Actions Semi
S700 SoC. SD0 is connected to uSD slot. Since there is no PMIC support
added yet, fixed regulator has been used as a regulator node.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since v1:
* No change.
Changes since RFC:
* No change.
---
arch/arm64/boot/dts/actions/s700-cubieboard7.dts | 41 ++++++++++++++++++++++++
arch/arm64/boot/dts/actions/s700.dtsi | 1 +
2 files changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
index 63e375cd9eb4..ec117eb12f3a 100644
--- a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
+++ b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
@@ -13,6 +13,7 @@
aliases {
serial3 = &uart3;
+ mmc0 = &mmc0;
};
chosen {
@@ -28,6 +29,23 @@
device_type = "memory";
reg = <0x1 0xe0000000 0x0 0x0>;
};
+
+ /* Fixed regulator used in the absence of PMIC */
+ vcc_3v1: vcc-3v1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <3100000>;
+ regulator-max-microvolt = <3100000>;
+ };
+
+ /* Fixed regulator used in the absence of PMIC */
+ sd_vcc: sd-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <3100000>;
+ regulator-max-microvolt = <3100000>;
+ regulator-always-on;
+ };
};
&i2c0 {
@@ -81,6 +99,14 @@
bias-pull-up;
};
};
+
+ mmc0_default: mmc0_default {
+ pinmux {
+ groups = "sd0_d0_mfp", "sd0_d1_mfp", "sd0_d2_d3_mfp",
+ "sd0_cmd_mfp", "sd0_clk_mfp";
+ function = "sd0";
+ };
+ };
};
&timer {
@@ -90,3 +116,18 @@
&uart3 {
status = "okay";
};
+
+/* uSD */
+&mmc0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_default>;
+ cd-gpios = <&pinctrl 120 GPIO_ACTIVE_LOW>;
+ no-sdio;
+ no-mmc;
+ no-1-8-v;
+ bus-width = <4>;
+ vmmc-supply = <&sd_vcc>;
+ vqmmc-supply = <&sd_vcc>;
+};
+
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 0d3ff315b00e..18700aeb8d2b 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -4,6 +4,7 @@
*/
#include <dt-bindings/clock/actions,s700-cmu.h>
+#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/actions,s700-reset.h>
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 01/14] dt-bindings: arm: add a binding document for MediaTek PERICFG controller
From: Rob Herring @ 2020-05-19 18:28 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Edwin Peer, devicetree, Stephane Le Provost, Arnd Bergmann,
Bartosz Golaszewski, netdev, Sean Wang, linux-kernel,
David S . Miller, Fabien Parent, Pedro Tsai, linux-mediatek,
Andrew Perepech, John Crispin, Matthias Brugger, Jakub Kicinski,
Mark Lee, linux-arm-kernel, Heiner Kallweit
In-Reply-To: <20200511150759.18766-2-brgl@bgdev.pl>
On Mon, May 11, 2020 at 05:07:46PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This adds a binding document for the PERICFG controller present on
> MediaTek SoCs. For now the only variant supported is 'mt8516-pericfg'.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> .../arm/mediatek/mediatek,pericfg.yaml | 34 +++++++++++++++++++
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
> new file mode 100644
> index 000000000000..74b2a6173ffb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
> @@ -0,0 +1,34 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,pericfg.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: MediaTek Peripheral Configuration Controller
> +
> +maintainers:
> + - Bartosz Golaszewski <bgolaszewski@baylibre.com>
> +
> +properties:
> + compatible:
> + oneOf:
Don't need oneOf here.
> + - items:
> + - enum:
> + - mediatek,pericfg
Doesn't match the example (which is correct).
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + pericfg: pericfg@10003050 {
> + compatible = "mediatek,mt8516-pericfg", "syscon";
> + reg = <0 0x10003050 0 0x1000>;
> + };
> --
> 2.25.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 07/10] dt-bindings: reset: s700: Add binding constants for mmc
From: Rob Herring @ 2020-05-19 18:33 UTC (permalink / raw)
To: Amit Singh Tomar
Cc: devicetree, andre.przywara, linux-actions, linux-kernel,
cristian.ciocaltea, manivannan.sadhasivam, afaerber,
linux-arm-kernel
In-Reply-To: <1589912368-480-8-git-send-email-amittomer25@gmail.com>
On Tue, May 19, 2020 at 11:49:25PM +0530, Amit Singh Tomar wrote:
> This commit adds device tree binding reset constants for mmc controller
> present on Actions S700 Soc.
>
> Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
> ---
> Changes since v1:
> * No change.
> Changes since RFC:
> * added Rob's acked-by tag
And dropped??
> ---
> include/dt-bindings/reset/actions,s700-reset.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/dt-bindings/reset/actions,s700-reset.h b/include/dt-bindings/reset/actions,s700-reset.h
> index 5e3b16b8ef53..a3118de6d7aa 100644
> --- a/include/dt-bindings/reset/actions,s700-reset.h
> +++ b/include/dt-bindings/reset/actions,s700-reset.h
> @@ -30,5 +30,8 @@
> #define RESET_UART4 20
> #define RESET_UART5 21
> #define RESET_UART6 22
> +#define RESET_SD0 23
> +#define RESET_SD1 24
> +#define RESET_SD2 25
>
> #endif /* __DT_BINDINGS_ACTIONS_S700_RESET_H */
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
From: Ira Weiny @ 2020-05-19 18:40 UTC (permalink / raw)
To: Guenter Roeck
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, dri-devel,
linux-mips, James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, Dan Williams, Helge Deller, x86,
linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Al Viro, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Chris Zankel,
Thomas Bogendoerfer, linux-parisc, linux-kernel, Christian Koenig,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200519165422.GA5838@roeck-us.net>
On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > The kunmap_atomic clean up failed to remove one set of pagefault/preempt
> > enables when vaddr is not in the fixmap.
> >
> > Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
> > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>
> microblazeel works with this patch,
Awesome... Andrew in my rush yesterday I should have put a reported by on the
patch for Guenter as well.
Sorry about that Guenter,
Ira
> as do the nosmp sparc32 boot tests,
> but sparc32 boot tests with SMP enabled still fail with lots of messages
> such as:
>
> BUG: Bad page state in process swapper/0 pfn:006a1
> page:f0933420 refcount:0 mapcount:1 mapping:(ptrval) index:0x1
> flags: 0x0()
> raw: 00000000 00000100 00000122 00000000 00000001 00000000 00000000 00000000
> page dumped because: nonzero mapcount
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Tainted: G B 5.7.0-rc6-next-20200518-00002-gb178d2d56f29 #1
> [f00e7ab8 :
> bad_page+0xa8/0x108 ]
> [f00e8b54 :
> free_pcppages_bulk+0x154/0x52c ]
> [f00ea024 :
> free_unref_page+0x54/0x6c ]
> [f00ed864 :
> free_reserved_area+0x58/0xec ]
> [f0527104 :
> kernel_init+0x14/0x110 ]
> [f000b77c :
> ret_from_kernel_thread+0xc/0x38 ]
> [00000000 :
> 0x0 ]
>
> Code path leading to that message is different but always the same
> from free_unref_page().
>
> Still testing ppc images.
>
> Guenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V1 RESEND 2/3] bindings/perf/imx-ddr: update compatible string
From: Rob Herring @ 2020-05-19 18:47 UTC (permalink / raw)
To: Joakim Zhang
Cc: mark.rutland, devicetree, will, john.garry, linux-kernel,
linux-imx, shawnguo, linux-arm-kernel
In-Reply-To: <20200512073115.14177-3-qiangqing.zhang@nxp.com>
On Tue, May 12, 2020 at 03:31:14PM +0800, Joakim Zhang wrote:
> Update compatible string according to driver change.`
Why?
You are breaking compatibility.
>
> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> ---
> Documentation/devicetree/bindings/perf/fsl-imx-ddr.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.txt b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.txt
> index 7822a806ea0a..b27a1d4fec78 100644
> --- a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.txt
> +++ b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.txt
> @@ -4,7 +4,9 @@ Required properties:
>
> - compatible: should be one of:
> "fsl,imx8-ddr-pmu"
> - "fsl,imx8m-ddr-pmu"
> + "fsl,imx8mq-ddr-pmu"
> + "fsl,imx8mm-ddr-pmu"
> + "fsl,imx8mn-ddr-pmu"
> "fsl,imx8mp-ddr-pmu"
>
> - reg: physical address and size
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v9] arm64: dts: qcom: sc7180: Add WCN3990 WLAN module device node
From: pillair @ 2020-05-19 18:50 UTC (permalink / raw)
To: 'Evan Green'
Cc: 'open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS',
'LKML', 'linux-arm Mailing List',
'linux-arm-msm'
In-Reply-To: <CAE=gft577zxP5F6OdFXt6taLuLyye+tdRqZa63mPSRtPXO3Lcw@mail.gmail.com>
Hi Evan,
> -----Original Message-----
> From: Evan Green <evgreen@chromium.org>
> Sent: Tuesday, May 19, 2020 10:58 PM
> To: Rakesh Pillai <pillair@codeaurora.org>
> Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> <devicetree@vger.kernel.org>; linux-arm Mailing List <linux-arm-
> kernel@lists.infradead.org>; LKML <linux-kernel@vger.kernel.org>; linux-
> arm-msm <linux-arm-msm@vger.kernel.org>
> Subject: Re: [PATCH v9] arm64: dts: qcom: sc7180: Add WCN3990 WLAN
> module device node
>
> On Sun, May 17, 2020 at 3:47 AM Rakesh Pillai <pillair@codeaurora.org>
> wrote:
> >
> > Add device node for the ath10k SNOC platform driver probe
> > and add resources required for WCN3990 on sc7180 soc.
> >
> > Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
> > ---
> > Changes from v8:
> > - Removed the qcom,msa-fixed-perm
> > ---
> > arch/arm64/boot/dts/qcom/sc7180-idp.dts | 7 +++++++
> > arch/arm64/boot/dts/qcom/sc7180.dtsi | 27
> +++++++++++++++++++++++++++
> > 2 files changed, 34 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> > index 4e9149d..38b102e 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> > +++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> > @@ -389,6 +389,13 @@
> > };
> > };
> >
> > +&wifi {
> > + status = "okay";
> > + wifi-firmware {
> > + iommus = <&apps_smmu 0xc2 0x1>;
> > + };
> > +};
> > +
> > /* PINCTRL - additions to nodes defined in sc7180.dtsi */
> >
> > &qspi_clk {
> > diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> > index f1280e0..dd4e095 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> > @@ -63,6 +63,11 @@
> > clock-frequency = <32764>;
> > #clock-cells = <0>;
> > };
> > +
> > + wlan_fw_mem: memory@94100000 {
> > + reg = <0 0x94100000 0 0x200000>;
> > + no-map;
> > + };
>
> This node is not in the right place. Up through v8, this lived inside
> reserved-memory. Here it seems to apply into the clocks {} node, which
> is not the right spot.
Thanks for spotting this. This was a rebase problem.
I will post the next patchset by fixing this.
>
>
> > };
> >
> > reserved_memory: reserved-memory {
> > @@ -944,6 +949,28 @@
> > };
> > };
> >
> > + wifi: wifi@18800000 {
> > + compatible = "qcom,wcn3990-wifi";
> > + reg = <0 0x18800000 0 0x800000>;
> > + reg-names = "membase";
> > + iommus = <&apps_smmu 0xc0 0x1>;
> > + interrupts =
> > + <GIC_SPI 414 IRQ_TYPE_LEVEL_HIGH /* CE0 */ >,
> > + <GIC_SPI 415 IRQ_TYPE_LEVEL_HIGH /* CE1 */ >,
> > + <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH /* CE2 */ >,
> > + <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH /* CE3 */ >,
> > + <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH /* CE4 */ >,
> > + <GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH /* CE5 */ >,
> > + <GIC_SPI 420 IRQ_TYPE_LEVEL_HIGH /* CE6 */ >,
> > + <GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH /* CE7 */ >,
> > + <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH /* CE8 */ >,
> > + <GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH /* CE9 */ >,
> > + <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH /* CE10 */>,
> > + <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH /* CE11 */>;
> > + memory-region = <&wlan_fw_mem>;
>
> Should any of the *-supply regulators be specified? Or are they all
> board specific? Or just not needed? The example has these:
> vdd-0.8-cx-mx-supply = <&pm8998_l5>;
> vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
> vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
> vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
These votes are optional and were required for older targets.
We do not need these proxy votes in host now.
>
>
>
> > + status = "disabled";
> > + };
> > +
> > config_noc: interconnect@1500000 {
> > compatible = "qcom,sc7180-config-noc";
> > reg = <0 0x01500000 0 0x28000>;
> > --
> > 2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier for userspace
From: Rob Herring @ 2020-05-19 18:51 UTC (permalink / raw)
To: Joakim Zhang
Cc: mark.rutland, devicetree, will, john.garry, linux-kernel,
linux-imx, shawnguo, linux-arm-kernel
In-Reply-To: <20200512073115.14177-2-qiangqing.zhang@nxp.com>
On Tue, May 12, 2020 at 03:31:13PM +0800, Joakim Zhang wrote:
> The DDR Perf for i.MX8 is a system PMU whose axi id would different from
> SoC to SoC. Need expose system PMU identifier for userspace which refer
> to /sys/bus/event_source/devices/<PMU DEVICE>/identifier.
Why not just expose the AXI ID if that's what's different?
>
> Reviewed-by: John Garry <john.garry@huawei.com>
> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> ---
> drivers/perf/fsl_imx8_ddr_perf.c | 45 +++++++++++++++++++++++++++++---
> 1 file changed, 42 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
> index 95dca2cb5265..88addbffbbd0 100644
> --- a/drivers/perf/fsl_imx8_ddr_perf.c
> +++ b/drivers/perf/fsl_imx8_ddr_perf.c
> @@ -50,21 +50,38 @@ static DEFINE_IDA(ddr_ida);
>
> struct fsl_ddr_devtype_data {
> unsigned int quirks; /* quirks needed for different DDR Perf core */
> + const char *identifier; /* system PMU identifier for userspace */
> };
>
> -static const struct fsl_ddr_devtype_data imx8_devtype_data;
> +static const struct fsl_ddr_devtype_data imx8_devtype_data = {
> + .identifier = "i.MX8",
> +};
> +
> +static const struct fsl_ddr_devtype_data imx8mq_devtype_data = {
> + .quirks = DDR_CAP_AXI_ID_FILTER,
> + .identifier = "i.MX8MQ",
> +};
> +
> +static const struct fsl_ddr_devtype_data imx8mm_devtype_data = {
> + .quirks = DDR_CAP_AXI_ID_FILTER,
> + .identifier = "i.MX8MM",
> +};
>
> -static const struct fsl_ddr_devtype_data imx8m_devtype_data = {
> +static const struct fsl_ddr_devtype_data imx8mn_devtype_data = {
> .quirks = DDR_CAP_AXI_ID_FILTER,
> + .identifier = "i.MX8MN",
> };
>
> static const struct fsl_ddr_devtype_data imx8mp_devtype_data = {
> .quirks = DDR_CAP_AXI_ID_FILTER_ENHANCED,
> + .identifier = "i.MX8MP",
> };
>
> static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
> { .compatible = "fsl,imx8-ddr-pmu", .data = &imx8_devtype_data},
> - { .compatible = "fsl,imx8m-ddr-pmu", .data = &imx8m_devtype_data},
You need to keep the old one for compatibility.
> + { .compatible = "fsl,imx8mq-ddr-pmu", .data = &imx8mq_devtype_data},
> + { .compatible = "fsl,imx8mm-ddr-pmu", .data = &imx8mm_devtype_data},
> + { .compatible = "fsl,imx8mn-ddr-pmu", .data = &imx8mn_devtype_data},
> { .compatible = "fsl,imx8mp-ddr-pmu", .data = &imx8mp_devtype_data},
> { /* sentinel */ }
> };
> @@ -84,6 +101,27 @@ struct ddr_pmu {
> int id;
> };
>
> +static ssize_t ddr_perf_identifier_show(struct device *dev,
> + struct device_attribute *attr,
> + char *page)
> +{
> + struct ddr_pmu *pmu = dev_get_drvdata(dev);
> +
> + return sprintf(page, "%s\n", pmu->devtype_data->identifier);
Why do we need yet another way to identify the SoC from userspace?
> +}
> +
> +static struct device_attribute ddr_perf_identifier_attr =
> + __ATTR(identifier, 0444, ddr_perf_identifier_show, NULL);
sysfs attributes are supposed to be documented.
> +
> +static struct attribute *ddr_perf_identifier_attrs[] = {
> + &ddr_perf_identifier_attr.attr,
> + NULL,
> +};
> +
> +static struct attribute_group ddr_perf_identifier_attr_group = {
> + .attrs = ddr_perf_identifier_attrs,
> +};
> +
> enum ddr_perf_filter_capabilities {
> PERF_CAP_AXI_ID_FILTER = 0,
> PERF_CAP_AXI_ID_FILTER_ENHANCED,
> @@ -237,6 +275,7 @@ static const struct attribute_group *attr_groups[] = {
> &ddr_perf_format_attr_group,
> &ddr_perf_cpumask_attr_group,
> &ddr_perf_filter_cap_attr_group,
> + &ddr_perf_identifier_attr_group,
> NULL,
> };
>
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v10] arm64: dts: qcom: sc7180: Add WCN3990 WLAN module device node
From: Rakesh Pillai @ 2020-05-19 18:53 UTC (permalink / raw)
To: devicetree; +Cc: linux-arm-msm, Rakesh Pillai, linux-kernel, linux-arm-kernel
Add device node for the ath10k SNOC platform driver probe
and add resources required for WCN3990 on sc7180 soc.
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
---
Changes from v9:
- Place the wlan_fw_mem under reserved-memory node
---
arch/arm64/boot/dts/qcom/sc7180-idp.dts | 7 +++++++
arch/arm64/boot/dts/qcom/sc7180.dtsi | 27 +++++++++++++++++++++++++++
2 files changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
index 4e9149d..38b102e 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
@@ -389,6 +389,13 @@
};
};
+&wifi {
+ status = "okay";
+ wifi-firmware {
+ iommus = <&apps_smmu 0xc2 0x1>;
+ };
+};
+
/* PINCTRL - additions to nodes defined in sc7180.dtsi */
&qspi_clk {
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index f1280e0..19bd7d0 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -106,6 +106,11 @@
no-map;
};
+ wlan_fw_mem: memory@94100000 {
+ reg = <0 0x94100000 0 0x200000>;
+ no-map;
+ };
+
rmtfs_mem: memory@84400000 {
compatible = "qcom,rmtfs-mem";
reg = <0x0 0x84400000 0x0 0x200000>;
@@ -944,6 +949,28 @@
};
};
+ wifi: wifi@18800000 {
+ compatible = "qcom,wcn3990-wifi";
+ reg = <0 0x18800000 0 0x800000>;
+ reg-names = "membase";
+ iommus = <&apps_smmu 0xc0 0x1>;
+ interrupts =
+ <GIC_SPI 414 IRQ_TYPE_LEVEL_HIGH /* CE0 */ >,
+ <GIC_SPI 415 IRQ_TYPE_LEVEL_HIGH /* CE1 */ >,
+ <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH /* CE2 */ >,
+ <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH /* CE3 */ >,
+ <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH /* CE4 */ >,
+ <GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH /* CE5 */ >,
+ <GIC_SPI 420 IRQ_TYPE_LEVEL_HIGH /* CE6 */ >,
+ <GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH /* CE7 */ >,
+ <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH /* CE8 */ >,
+ <GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH /* CE9 */ >,
+ <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH /* CE10 */>,
+ <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH /* CE11 */>;
+ memory-region = <&wlan_fw_mem>;
+ status = "disabled";
+ };
+
config_noc: interconnect@1500000 {
compatible = "qcom,sc7180-config-noc";
reg = <0 0x01500000 0 0x28000>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 1/2] dt-bindings: soc: ti: add binding for k3 platforms chipid module
From: Rob Herring @ 2020-05-19 18:54 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Nishanth Menon, devicetree, Arnd Bergmann, Dave Gerlach,
Lokesh Vutla, Sekhar Nori, linux-kernel, Tero Kristo, Rob Herring,
Santosh Shilimkar, linux-arm-kernel
In-Reply-To: <20200512123449.16517-2-grygorii.strashko@ti.com>
On Tue, 12 May 2020 15:34:48 +0300, Grygorii Strashko wrote:
> Add DT binding for Texas Instruments K3 Multicore SoC platforms chipid
> module which is represented by CTRLMMR_xxx_JTAGID register and contains
> information about SoC id and revision.
>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
> Reviewed-by: Tero Kristo <t-kristo@ti.com>
> ---
> .../bindings/soc/ti/k3-socinfo.yaml | 40 +++++++++++++++++++
> 1 file changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: nvmem: stm32: new property for data access
From: Rob Herring @ 2020-05-19 19:00 UTC (permalink / raw)
To: Etienne Carriere
Cc: Etienne Carriere, devicetree, alexandre.torgue, linux-kernel,
robh+dt, srinivas.kandagatla, mcoquelin.stm32, fabrice.gasnier,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200512131334.1750-1-etienne.carriere@linaro.org>
On Tue, 12 May 2020 15:13:34 +0200, Etienne Carriere wrote:
> From: Etienne Carriere <etienne.carriere@st.com>
>
> Introduce boolean property st,non-secure-otp for OTP data located
> in a factory programmed area that only secure firmware can access
> by default and that shall be reachable from the non-secure world.
>
> This change also allows additional properties for NVMEM nodes that
> were forbidden prior this change.
>
> Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
> ---
> Changes since v1:
> Change nvmem.yaml to allow additional properties in NVMEM nodes.
>
> Link to v1:
> https://lore.kernel.org/patchwork/patch/1239028/
>
> .../devicetree/bindings/nvmem/nvmem.yaml | 2 --
> .../bindings/nvmem/st,stm32-romem.yaml | 17 +++++++++++++++++
> 2 files changed, 17 insertions(+), 2 deletions(-)
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 07/10] dt-bindings: reset: s700: Add binding constants for mmc
From: Amit Singh Tomar @ 2020-05-19 19:00 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: devicetree, linux-actions, linux-kernel, linux-arm-kernel,
cristian.ciocaltea
In-Reply-To: <1589912368-480-8-git-send-email-amittomer25@gmail.com>
This commit adds device tree binding reset constants for mmc controller
present on Actions S700 Soc.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since v1:
* No change.
Changes since RFC:
* added Rob's acked-by tag
---
include/dt-bindings/reset/actions,s700-reset.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/dt-bindings/reset/actions,s700-reset.h b/include/dt-bindings/reset/actions,s700-reset.h
index 5e3b16b8ef53..a3118de6d7aa 100644
--- a/include/dt-bindings/reset/actions,s700-reset.h
+++ b/include/dt-bindings/reset/actions,s700-reset.h
@@ -30,5 +30,8 @@
#define RESET_UART4 20
#define RESET_UART5 21
#define RESET_UART6 22
+#define RESET_SD0 23
+#define RESET_SD1 24
+#define RESET_SD2 25
#endif /* __DT_BINDINGS_ACTIONS_S700_RESET_H */
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr
From: Ard Biesheuvel @ 2020-05-19 19:02 UTC (permalink / raw)
To: linux-crypto; +Cc: ebiggers, Stephan Mueller, Ard Biesheuvel, linux-arm-kernel
Stephan reports that the arm64 implementation of cts(cbc(aes)) deviates
from the generic implementation in what it returns as the output IV. So
fix this, and add some test vectors to catch other non-compliant
implementations.
Stephan, could you provide a reference for the NIST validation tool and
how it flags this behaviour as non-compliant? Thanks.
Cc: Stephan Mueller <smueller@chronox.de>
Ard Biesheuvel (2):
crypto: arm64/aes - align output IV with generic CBC-CTS driver
crypto: testmgr - add output IVs for AES-CBC with ciphertext stealing
arch/arm64/crypto/aes-modes.S | 2 ++
crypto/testmgr.h | 12 ++++++++++++
2 files changed, 14 insertions(+)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC/RFT PATCH 2/2] crypto: testmgr - add output IVs for AES-CBC with ciphertext stealing
From: Ard Biesheuvel @ 2020-05-19 19:02 UTC (permalink / raw)
To: linux-crypto; +Cc: ebiggers, Stephan Mueller, Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200519190211.76855-1-ardb@kernel.org>
Add some test vectors to get coverage for the IV that is output by CTS
implementations.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
crypto/testmgr.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index d29983908c38..d45fa1ad91ee 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -31041,6 +31041,8 @@ static const struct cipher_testvec cts_mode_tv_template[] = {
.ctext = "\xc6\x35\x35\x68\xf2\xbf\x8c\xb4"
"\xd8\xa5\x80\x36\x2d\xa7\xff\x7f"
"\x97",
+ .iv_out = "\xc6\x35\x35\x68\xf2\xbf\x8c\xb4"
+ "\xd8\xa5\x80\x36\x2d\xa7\xff\x7f",
}, {
.klen = 16,
.key = "\x63\x68\x69\x63\x6b\x65\x6e\x20"
@@ -31054,6 +31056,8 @@ static const struct cipher_testvec cts_mode_tv_template[] = {
"\xd4\x45\xd4\xc8\xef\xf7\xed\x22"
"\x97\x68\x72\x68\xd6\xec\xcc\xc0"
"\xc0\x7b\x25\xe2\x5e\xcf\xe5",
+ .iv_out = "\xfc\x00\x78\x3e\x0e\xfd\xb2\xc1"
+ "\xd4\x45\xd4\xc8\xef\xf7\xed\x22",
}, {
.klen = 16,
.key = "\x63\x68\x69\x63\x6b\x65\x6e\x20"
@@ -31067,6 +31071,8 @@ static const struct cipher_testvec cts_mode_tv_template[] = {
"\xbe\x7f\xcb\xcc\x98\xeb\xf5\xa8"
"\x97\x68\x72\x68\xd6\xec\xcc\xc0"
"\xc0\x7b\x25\xe2\x5e\xcf\xe5\x84",
+ .iv_out = "\x39\x31\x25\x23\xa7\x86\x62\xd5"
+ "\xbe\x7f\xcb\xcc\x98\xeb\xf5\xa8",
}, {
.klen = 16,
.key = "\x63\x68\x69\x63\x6b\x65\x6e\x20"
@@ -31084,6 +31090,8 @@ static const struct cipher_testvec cts_mode_tv_template[] = {
"\x1b\x55\x49\xd2\xf8\x38\x02\x9e"
"\x39\x31\x25\x23\xa7\x86\x62\xd5"
"\xbe\x7f\xcb\xcc\x98\xeb\xf5",
+ .iv_out = "\xb3\xff\xfd\x94\x0c\x16\xa1\x8c"
+ "\x1b\x55\x49\xd2\xf8\x38\x02\x9e",
}, {
.klen = 16,
.key = "\x63\x68\x69\x63\x6b\x65\x6e\x20"
@@ -31101,6 +31109,8 @@ static const struct cipher_testvec cts_mode_tv_template[] = {
"\x3b\xc1\x03\xe1\xa1\x94\xbb\xd8"
"\x39\x31\x25\x23\xa7\x86\x62\xd5"
"\xbe\x7f\xcb\xcc\x98\xeb\xf5\xa8",
+ .iv_out = "\x9d\xad\x8b\xbb\x96\xc4\xcd\xc0"
+ "\x3b\xc1\x03\xe1\xa1\x94\xbb\xd8",
}, {
.klen = 16,
.key = "\x63\x68\x69\x63\x6b\x65\x6e\x20"
@@ -31122,6 +31132,8 @@ static const struct cipher_testvec cts_mode_tv_template[] = {
"\x26\x73\x0d\xbc\x2f\x7b\xc8\x40"
"\x9d\xad\x8b\xbb\x96\xc4\xcd\xc0"
"\x3b\xc1\x03\xe1\xa1\x94\xbb\xd8",
+ .iv_out = "\x48\x07\xef\xe8\x36\xee\x89\xa5"
+ "\x26\x73\x0d\xbc\x2f\x7b\xc8\x40",
}
};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC/RFT PATCH 1/2] crypto: arm64/aes - align output IV with generic CBC-CTS driver
From: Ard Biesheuvel @ 2020-05-19 19:02 UTC (permalink / raw)
To: linux-crypto; +Cc: ebiggers, Stephan Mueller, Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200519190211.76855-1-ardb@kernel.org>
The generic CTS chaining mode wraps the CBC mode driver in a way that
results in the IV buffer referenced by the skcipher request to be
updated with the last block of ciphertext. The arm64 implementation
deviates from this, given that CTS itself does not specify the concept
of an output IV, or how it should be generated, and so it was assumed
that the output IV does not matter.
However, Stephan reports that code exists that relies on this behavior,
and that there is even a NIST validation tool that flags it as
non-compliant [citation needed. Stephan?]
So let's align with the generic implementation here, and return the
penultimate block of ciphertext as the output IV.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/crypto/aes-modes.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-modes.S
index cf618d8f6cec..80832464df50 100644
--- a/arch/arm64/crypto/aes-modes.S
+++ b/arch/arm64/crypto/aes-modes.S
@@ -275,6 +275,7 @@ AES_FUNC_START(aes_cbc_cts_encrypt)
add x4, x0, x4
st1 {v0.16b}, [x4] /* overlapping stores */
st1 {v1.16b}, [x0]
+ st1 {v1.16b}, [x5]
ret
AES_FUNC_END(aes_cbc_cts_encrypt)
@@ -291,6 +292,7 @@ AES_FUNC_START(aes_cbc_cts_decrypt)
ld1 {v1.16b}, [x1]
ld1 {v5.16b}, [x5] /* get iv */
+ st1 {v0.16b}, [x5]
dec_prepare w3, x2, x6
decrypt_block v0, w3, x2, x6, w7
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 07/10] dt-bindings: reset: s700: Add binding constants for mmc
From: Amit Tomer @ 2020-05-19 19:03 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Andre Przywara, linux-actions, linux-kernel,
cristian.ciocaltea, Manivannan Sadhasivam, Andreas Färber,
linux-arm-kernel
In-Reply-To: <20200519183345.GA434412@bogus>
Hi,
On Wed, May 20, 2020 at 12:03 AM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, May 19, 2020 at 11:49:25PM +0530, Amit Singh Tomar wrote:
> > This commit adds device tree binding reset constants for mmc controller
> > present on Actions S700 Soc.
> >
> > Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
> > ---
> > Changes since v1:
> > * No change.
> > Changes since RFC:
> > * added Rob's acked-by tag
>
> And dropped??
Sorry, I just forgot to add it.
Thanks
-Amit
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr
From: Ard Biesheuvel @ 2020-05-19 19:04 UTC (permalink / raw)
To: Linux Crypto Mailing List, Gilad Ben-Yossef
Cc: Eric Biggers, Stephan Mueller, Linux ARM
In-Reply-To: <20200519190211.76855-1-ardb@kernel.org>
(add Gilad for cc-ree)
On Tue, 19 May 2020 at 21:02, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> Stephan reports that the arm64 implementation of cts(cbc(aes)) deviates
> from the generic implementation in what it returns as the output IV. So
> fix this, and add some test vectors to catch other non-compliant
> implementations.
>
> Stephan, could you provide a reference for the NIST validation tool and
> how it flags this behaviour as non-compliant? Thanks.
>
> Cc: Stephan Mueller <smueller@chronox.de>
>
> Ard Biesheuvel (2):
> crypto: arm64/aes - align output IV with generic CBC-CTS driver
> crypto: testmgr - add output IVs for AES-CBC with ciphertext stealing
>
> arch/arm64/crypto/aes-modes.S | 2 ++
> crypto/testmgr.h | 12 ++++++++++++
> 2 files changed, 14 insertions(+)
>
> --
> 2.20.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: gpu: arm, mali-utgard: add additional properties
From: Heiko Stübner @ 2020-05-19 19:06 UTC (permalink / raw)
To: Johan Jonker
Cc: devicetree, airlied, linux-kernel, dri-devel, linux-rockchip,
robh+dt, daniel, maxime.ripard, linux-arm-kernel
In-Reply-To: <20200519164425.9729-1-jbx6244@gmail.com>
Hi,
Am Dienstag, 19. Mai 2020, 18:44:25 CEST schrieb Johan Jonker:
> In the old txt situation we add/describe only properties that are used
> by the driver/hardware itself. With yaml it also filters things in a
> node that are used by other drivers like 'assigned-clocks' and
> 'assigned-clock-rates' for some older Rockchip SoCs in 'gpu' nodes,
> so add them to 'arm,mali-utgard.yaml'.
though the other option would be to just get rid assigned-clocks
in dt-node for utgard malis ;-)
Like any good gpu, lima should just use frequency scaling to achieve
suitable (fast <-> powersaving) frequencies and it looks like a set
of patches for this was posted in december already [0].
So I guess one could expect opp-based scaling to land at some point.
Heiko
[0] https://lwn.net/Articles/807444/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
From: Guenter Roeck @ 2020-05-19 19:42 UTC (permalink / raw)
To: Ira Weiny
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, dri-devel,
linux-mips, James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, Dan Williams, Helge Deller, x86,
linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Al Viro, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Chris Zankel,
Thomas Bogendoerfer, linux-parisc, linux-kernel, Christian Koenig,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200519184031.GB3356843@iweiny-DESK2.sc.intel.com>
On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> > On Mon, May 18, 2020 at 11:48:43AM -0700, ira.weiny@intel.com wrote:
> > > From: Ira Weiny <ira.weiny@intel.com>
> > >
> > > The kunmap_atomic clean up failed to remove one set of pagefault/preempt
> > > enables when vaddr is not in the fixmap.
> > >
> > > Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
> > > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> >
> > microblazeel works with this patch,
>
> Awesome... Andrew in my rush yesterday I should have put a reported by on the
> patch for Guenter as well.
>
> Sorry about that Guenter,
No worries.
> Ira
>
> > as do the nosmp sparc32 boot tests,
> > but sparc32 boot tests with SMP enabled still fail with lots of messages
> > such as:
> >
> > BUG: Bad page state in process swapper/0 pfn:006a1
> > page:f0933420 refcount:0 mapcount:1 mapping:(ptrval) index:0x1
> > flags: 0x0()
> > raw: 00000000 00000100 00000122 00000000 00000001 00000000 00000000 00000000
> > page dumped because: nonzero mapcount
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper/0 Tainted: G B 5.7.0-rc6-next-20200518-00002-gb178d2d56f29 #1
> > [f00e7ab8 :
> > bad_page+0xa8/0x108 ]
> > [f00e8b54 :
> > free_pcppages_bulk+0x154/0x52c ]
> > [f00ea024 :
> > free_unref_page+0x54/0x6c ]
> > [f00ed864 :
> > free_reserved_area+0x58/0xec ]
> > [f0527104 :
> > kernel_init+0x14/0x110 ]
> > [f000b77c :
> > ret_from_kernel_thread+0xc/0x38 ]
> > [00000000 :
> > 0x0 ]
> >
> > Code path leading to that message is different but always the same
> > from free_unref_page().
> >
> > Still testing ppc images.
> >
ppc image tests are passing with this patch.
Guenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/11] genirq: Add fasteoi IPI flow
From: Florian Fainelli @ 2020-05-19 19:47 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, linux-kernel
Cc: Sumit Garg, Russell King, Jason Cooper, Will Deacon,
Catalin Marinas, Thomas Gleixner, kernel-team
In-Reply-To: <20200519161755.209565-2-maz@kernel.org>
On 5/19/2020 9:17 AM, Marc Zyngier wrote:
> For irqchips using the fasteoi flow, IPIs are a bit special.
>
> They need to be EOId early (before calling the handler), as
> funny things may happen in the handler (they do not necessarily
> behave like a normal interrupt), and that the arch code is
> already handling the stats.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> include/linux/irq.h | 1 +
> kernel/irq/chip.c | 26 ++++++++++++++++++++++++++
> 2 files changed, 27 insertions(+)
>
> diff --git a/include/linux/irq.h b/include/linux/irq.h
> index 8d5bc2c237d7..726f94d8b8cc 100644
> --- a/include/linux/irq.h
> +++ b/include/linux/irq.h
> @@ -621,6 +621,7 @@ static inline int irq_set_parent(int irq, int parent_irq)
> */
> extern void handle_level_irq(struct irq_desc *desc);
> extern void handle_fasteoi_irq(struct irq_desc *desc);
> +extern void handle_percpu_devid_fasteoi_ipi(struct irq_desc *desc);
> extern void handle_edge_irq(struct irq_desc *desc);
> extern void handle_edge_eoi_irq(struct irq_desc *desc);
> extern void handle_simple_irq(struct irq_desc *desc);
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index 41e7e37a0928..7b0b789cfed4 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -955,6 +955,32 @@ void handle_percpu_devid_irq(struct irq_desc *desc)
> chip->irq_eoi(&desc->irq_data);
> }
>
> +/**
> + * handle_percpu_devid_fasteoi_ipi - Per CPU local IPI handler with per cpu
> + * dev ids
> + * @desc: the interrupt description structure for this irq
> + *
> + * The biggest differences with the IRQ version are that:
> + * - the interrupt is EOIed early, as the IPI could result in a context
> + * switch, and we need to make sure the IPI can fire again
> + * - Stats are usually handled at the architecture level, so we ignore them
> + * here
> + */
> +void handle_percpu_devid_fasteoi_ipi(struct irq_desc *desc)
> +{
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct irqaction *action = desc->action;
> + unsigned int irq = irq_desc_get_irq(desc);
> + irqreturn_t res;
Should not this have a:
if (!irq_settings_is_no_accounting(desc))
__kstat_incr_irqs_this_cpu(desc);
here in case you are using that handler with a SGI interrupt which is
not used as an IPI?
> +
> + if (chip->irq_eoi)
> + chip->irq_eoi(&desc->irq_data);
> +
> + trace_irq_handler_entry(irq, action);
> + res = action->handler(irq, raw_cpu_ptr(action->percpu_dev_id));
> + trace_irq_handler_exit(irq, action, res);
> +}
> +
> /**
> * handle_percpu_devid_fasteoi_nmi - Per CPU local NMI handler with per cpu
> * dev ids
>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/11] arm/arm64: Turning IPIs into normal interrupts
From: Florian Fainelli @ 2020-05-19 19:47 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, linux-kernel
Cc: Sumit Garg, Russell King, Jason Cooper, Will Deacon,
Catalin Marinas, Thomas Gleixner, kernel-team
In-Reply-To: <d1ac7873-0f02-dbe0-dd3c-4fd14a87cf03@gmail.com>
On 5/19/2020 10:50 AM, Florian Fainelli wrote:
>
>
> On 5/19/2020 9:17 AM, Marc Zyngier wrote:
>> For as long as SMP ARM has existed, IPIs have been handled as
>> something special. The arch code and the interrupt controller exchange
>> a couple of hooks (one to generate an IPI, another to handle it).
>>
>> Although this is perfectly manageable, it prevents the use of features
>> that we could use if IPIs were Linux IRQs (such as pseudo-NMIs). It
>> also means that each interrupt controller driver has to follow an
>> architecture-specific interface instead of just implementing the base
>> irqchip functionnalities. The arch code also duplicates a number of
>> things that the core irq code already does (such as calling
>> set_irq_regs(), irq_enter()...).
>>
>> This series tries to remedy this on arm/arm64 by offering a new
>> registration interface where the irqchip gives the arch code a range
>> of interrupts to use for IPIs. The arch code requests these as normal
>> interrupts.
>>
>> The bulk of the work is at the interrupt controller level, where all 3
>> irqchips used on arm64 get converted.
>>
>> Finally, the arm64 code drops the legacy registration interface. The
>> same thing could be done on 32bit as well once the two remaining
>> irqchips using that interface get converted.
>>
>> There is probably more that could be done: statistics are still
>> architecture-private code, for example, and no attempt is made to
>> solve that (apart from hidding the IRQs from /proc/interrupt).
>>
>> This has been tested on a bunch of 32 and 64bit guests.
>
> Does this patch series change your position on this patch series
>
> https://lore.kernel.org/linux-arm-kernel/20191023000547.7831-3-f.fainelli@gmail.com/T/
>
> or is this still a no-no?
Our firmware specifies SGI interrupts with the first interrupt cell
specifier set to 2, so changing GIC_IRQ_TYPE_SGI to 2 allows me to use a
nearly unmodified firmware with your changes, sweet! I know this is not
supposed to be used that way, but the temptation was too big.
FWIW, on ARM64:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* clock_gettime64 vdso bug on 32-bit arm, rpi-4
From: Arnd Bergmann @ 2020-05-19 19:54 UTC (permalink / raw)
To: Vincenzo Frascino, Russell King - ARM Linux
Cc: Rich Felker, Szabolcs Nagy, Will Deacon,
Linux Kernel Mailing List, Stephen Boyd, Adhemerval Zanella,
Thomas Gleixner, Jack Schmidt, Linux ARM
Jack Schmidt reported a bug for the arm32 clock_gettimeofday64 vdso call last
month: https://github.com/richfelker/musl-cross-make/issues/96 and
https://github.com/raspberrypi/linux/issues/3579
As Will Deacon pointed out, this was never reported on the mailing list,
so I'll try to summarize what we know, so this can hopefully be resolved soon.
- This happened reproducibly on Linux-5.6 on a 32-bit Raspberry Pi patched
kernel running on a 64-bit Raspberry Pi 4b (bcm2711) when calling
clock_gettime64(CLOCK_REALTIME)
- The kernel tree is at https://github.com/raspberrypi/linux/, but I could
see no relevant changes compared to a mainline kernel.
- From the report, I see that the returned time value is larger than the
expected time, by 3.4 to 14.5 million seconds in four samples, my
guess is that a random number gets added in at some point.
- From other sources, I found that the Raspberry Pi clocksource runs
at 54 MHz, with a mask value of 0xffffffffffffff. From these numbers
I would expect that reading a completely random hardware register
value would result in an offset up to 1.33 billion seconds, which is
around factor 100 more than the error we see, though similar.
- The test case calls the musl clock_gettime() function, which falls back to
the clock_gettime64() syscall on kernels prior to 5.5, or to the 32-bit
clock_gettime() prior to Linux-5.1. As reported in the bug, Linux-4.19 does
not show the bug.
- The behavior was not reproduced on the same user space in qemu,
though I cannot tell whether the exact same kernel binary was used.
- glibc-2.31 calls the same clock_gettime64() vdso function on arm to
implement clock_gettime(), but earlier versions did not. I have not
seen any reports of this bug, which could be explained by users
generally being on older versions.
- As far as I can tell, there are no reports of this bug from other users,
and so far nobody could reproduce it.
- The current musl git tree has been patched to not call clock_gettime64
on ARM because of this problem, so it cannot be used for reproducing it.
If anyone has other information that may help figure out what is going
on, please share.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10] arm64: dts: qcom: sc7180: Add WCN3990 WLAN module device node
From: Doug Anderson @ 2020-05-19 20:07 UTC (permalink / raw)
To: Rakesh Pillai
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
Linux ARM, linux-arm-msm
In-Reply-To: <1589914405-6674-1-git-send-email-pillair@codeaurora.org>
Hi,
On Tue, May 19, 2020 at 11:53 AM Rakesh Pillai <pillair@codeaurora.org> wrote:
>
> Add device node for the ath10k SNOC platform driver probe
> and add resources required for WCN3990 on sc7180 soc.
>
> Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
> ---
> Changes from v9:
> - Place the wlan_fw_mem under reserved-memory node
> ---
> arch/arm64/boot/dts/qcom/sc7180-idp.dts | 7 +++++++
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 27 +++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> index 4e9149d..38b102e 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> @@ -389,6 +389,13 @@
> };
> };
>
> +&wifi {
> + status = "okay";
> + wifi-firmware {
> + iommus = <&apps_smmu 0xc2 0x1>;
> + };
> +};
> +
> /* PINCTRL - additions to nodes defined in sc7180.dtsi */
>
> &qspi_clk {
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index f1280e0..19bd7d0 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -106,6 +106,11 @@
> no-map;
> };
>
> + wlan_fw_mem: memory@94100000 {
> + reg = <0 0x94100000 0 0x200000>;
> + no-map;
> + };
> +
> rmtfs_mem: memory@84400000 {
> compatible = "qcom,rmtfs-mem";
> reg = <0x0 0x84400000 0x0 0x200000>;
This is less wrong than v9, but still a little wrong. You should be
keeping these ordered by unit address. 94100000 comes after 84400000.
-Doug
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 0/4] support reserving crashkernel above 4G on arm64 kdump
From: John Donnelly @ 2020-05-19 20:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: John Donnelly, open list:DOCUMENTATION, Chen Zhou,
Catalin Marinas, Bhupesh Sharma, Dave Young, kexec mailing list,
linux-kernel@vger.kernel.org, Simon Horman, James Morse,
Thomas Gleixner, Prabhakar Kushwaha, Will Deacon, Ingo Molnar,
Linux ARM
In-Reply-To: <CAK8P3a2VrAqefPYF2JqRjwdhgTDtORUgWgVuYxRYWqKxE3+5pA@mail.gmail.com>
> On May 19, 2020, at 5:21 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Mar 26, 2020 at 4:10 AM Chen Zhou <chenzhou10@huawei.com> wrote:
>>
>> Hi all,
>>
>> Friendly ping...
>
> I was asked about this patch series, and see that you last posted it in
> December. I think you should rebase it to linux-5.7-rc6 and post the
> entire series again to make progress, as it's unlikely that any maintainer
> would pick up the patches from last year.
>
> For the contents, everything seems reasonable to me, but I noticed that
> you are adding a property to the /chosen node without adding the
> corresponding documentation to
> Documentation/devicetree/bindings/chosen.txt
>
> Please add that, and Cc the devicetree maintainers on the updated
> patch.
>
> Arnd
>
>> On 2019/12/23 23:23, Chen Zhou wrote:
>>> This patch series enable reserving crashkernel above 4G in arm64.
>>>
>>> There are following issues in arm64 kdump:
>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>> when there is no enough low memory.
>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>>> in this case, if swiotlb or DMA buffers are required, crash dump kernel
>>> will boot failure because there is no low memory available for allocation.
>>>
>>> The previous changes and discussions can be retrieved from:
>>>
>>> Changes since [v6]
>>> - Fix build errors reported by kbuild test robot.
> ...
Hi
We found
https://lkml.org/lkml/2020/4/30/1583
Has cured our Out-Of-Memory kdump failures.
From Henry Willard
Subject [PATCH] mm: Limit boost_watermark on small zones.
I am currently not on linux-kernel@vger.kernel.org. dlist for all to see this message so you may want to rebase and see if this cures your OoM issue and share the results.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: clock_gettime64 vdso bug on 32-bit arm, rpi-4
From: Adhemerval Zanella @ 2020-05-19 20:24 UTC (permalink / raw)
To: Arnd Bergmann, Vincenzo Frascino, Russell King - ARM Linux
Cc: Rich Felker, Szabolcs Nagy, Will Deacon,
Linux Kernel Mailing List, Stephen Boyd, Thomas Gleixner,
Jack Schmidt, Linux ARM
In-Reply-To: <CAK8P3a2Tw2w73ZkK-W6AA9veMK4-miLUx-TL1EuOdP7EdW-AmQ@mail.gmail.com>
On 19/05/2020 16:54, Arnd Bergmann wrote:
> Jack Schmidt reported a bug for the arm32 clock_gettimeofday64 vdso call last
> month: https://github.com/richfelker/musl-cross-make/issues/96 and
> https://github.com/raspberrypi/linux/issues/3579
>
> As Will Deacon pointed out, this was never reported on the mailing list,
> so I'll try to summarize what we know, so this can hopefully be resolved soon.
>
> - This happened reproducibly on Linux-5.6 on a 32-bit Raspberry Pi patched
> kernel running on a 64-bit Raspberry Pi 4b (bcm2711) when calling
> clock_gettime64(CLOCK_REALTIME)
Does it happen with other clocks as well?
>
> - The kernel tree is at https://github.com/raspberrypi/linux/, but I could
> see no relevant changes compared to a mainline kernel.
Is this bug reproducible with mainline kernel or mainline kernel can't be
booted on bcm2711?
>
> - From the report, I see that the returned time value is larger than the
> expected time, by 3.4 to 14.5 million seconds in four samples, my
> guess is that a random number gets added in at some point.
What kind code are you using to reproduce it? It is threaded or issue
clock_gettime from signal handlers?
>
> - From other sources, I found that the Raspberry Pi clocksource runs
> at 54 MHz, with a mask value of 0xffffffffffffff. From these numbers
> I would expect that reading a completely random hardware register
> value would result in an offset up to 1.33 billion seconds, which is
> around factor 100 more than the error we see, though similar.
>
> - The test case calls the musl clock_gettime() function, which falls back to
> the clock_gettime64() syscall on kernels prior to 5.5, or to the 32-bit
> clock_gettime() prior to Linux-5.1. As reported in the bug, Linux-4.19 does
> not show the bug.
>
> - The behavior was not reproduced on the same user space in qemu,
> though I cannot tell whether the exact same kernel binary was used.
>
> - glibc-2.31 calls the same clock_gettime64() vdso function on arm to
> implement clock_gettime(), but earlier versions did not. I have not
> seen any reports of this bug, which could be explained by users
> generally being on older versions.
>
> - As far as I can tell, there are no reports of this bug from other users,
> and so far nobody could reproduce it.
>
> - The current musl git tree has been patched to not call clock_gettime64
> on ARM because of this problem, so it cannot be used for reproducing it.
So should glibc follow musl and remove arm clock_gettime6y4 vDSO support
or this bug is localized to an specific kernel version running on an
specific hardware?
>
> If anyone has other information that may help figure out what is going
> on, please share.
>
> Arnd
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox