* [PATCH 05/45] ARM: dts: at91: at91sam9260: TC blocks are also simple-mfd and syscon devices
From: Alexandre Belloni @ 2017-12-19 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219213209.13823-1-alexandre.belloni@free-electrons.com>
Add simple-mfd and syscon to the TC blocks to allow to register one of the
channels as clocksource properly at boot time and free up the remaining
channels for other use.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/boot/dts/at91sam9260.dtsi | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index bc655e7332d6..655f06cd716a 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -386,7 +386,9 @@
};
tcb0: timer at fffa0000 {
- compatible = "atmel,at91rm9200-tcb";
+ compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0xfffa0000 0x100>;
interrupts = <17 IRQ_TYPE_LEVEL_HIGH 0
18 IRQ_TYPE_LEVEL_HIGH 0
@@ -396,7 +398,9 @@
};
tcb1: timer@fffdc000 {
- compatible = "atmel,at91rm9200-tcb";
+ compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0xfffdc000 0x100>;
interrupts = <26 IRQ_TYPE_LEVEL_HIGH 0
27 IRQ_TYPE_LEVEL_HIGH 0
--
2.15.1
^ permalink raw reply related
* [PATCH 04/45] ARM: dts: at91: mpa1600: use TCB0 as timers
From: Alexandre Belloni @ 2017-12-19 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219213209.13823-1-alexandre.belloni@free-electrons.com>
Use tcb0 for timers as selected in at91_dt_defconfig.
Cc: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/boot/dts/mpa1600.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/mpa1600.dts b/arch/arm/boot/dts/mpa1600.dts
index 36cfa215620d..43aaa67fcd87 100644
--- a/arch/arm/boot/dts/mpa1600.dts
+++ b/arch/arm/boot/dts/mpa1600.dts
@@ -32,6 +32,18 @@
status = "okay";
};
+ tcb0: timer at fffa0000 {
+ timer at 0 {
+ compatible = "atmel,tcb-timer";
+ reg = <0>, <1>;
+ };
+
+ timer at 2 {
+ compatible = "atmel,tcb-timer";
+ reg = <2>;
+ };
+ };
+
macb0: ethernet at fffbc000 {
phy-mode = "rmii";
status = "okay";
--
2.15.1
^ permalink raw reply related
* [PATCH 03/45] ARM: dts: at91: at91rm9200ek: use TCB0 for timers
From: Alexandre Belloni @ 2017-12-19 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219213209.13823-1-alexandre.belloni@free-electrons.com>
Use tcb0 for timers like selected in at91_dt_defconfig.
Tested-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/boot/dts/at91rm9200ek.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
index 33192d0cefee..81aaf8151c76 100644
--- a/arch/arm/boot/dts/at91rm9200ek.dts
+++ b/arch/arm/boot/dts/at91rm9200ek.dts
@@ -32,6 +32,18 @@
ahb {
apb {
+ tcb0: timer at fffa0000 {
+ timer at 0 {
+ compatible = "atmel,tcb-timer";
+ reg = <0>, <1>;
+ };
+
+ timer at 2 {
+ compatible = "atmel,tcb-timer";
+ reg = <2>;
+ };
+ };
+
usb1: gadget at fffb0000 {
atmel,vbus-gpio = <&pioD 4 GPIO_ACTIVE_HIGH>;
atmel,pullup-gpio = <&pioD 5 GPIO_ACTIVE_HIGH>;
--
2.15.1
^ permalink raw reply related
* [PATCH 02/45] ARM: dts: at91: at91rm9200: TC blocks are also simple-mfd and syscon devices
From: Alexandre Belloni @ 2017-12-19 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219213209.13823-1-alexandre.belloni@free-electrons.com>
Add simple-mfd and syscon to the TC blocks to allow to register one of the
channels as clocksource properly at boot time and free up the remaining
channels for other use.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/boot/dts/at91rm9200.dtsi | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/at91rm9200.dtsi b/arch/arm/boot/dts/at91rm9200.dtsi
index da622bf45b4a..ba61893a02a0 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -375,7 +375,9 @@
};
tcb0: timer at fffa0000 {
- compatible = "atmel,at91rm9200-tcb";
+ compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0xfffa0000 0x100>;
interrupts = <17 IRQ_TYPE_LEVEL_HIGH 0
18 IRQ_TYPE_LEVEL_HIGH 0
@@ -385,7 +387,9 @@
};
tcb1: timer@fffa4000 {
- compatible = "atmel,at91rm9200-tcb";
+ compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0xfffa4000 0x100>;
interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0
21 IRQ_TYPE_LEVEL_HIGH 0
--
2.15.1
^ permalink raw reply related
* [PATCH 01/45] ARM: at91: Document new TCB bindings
From: Alexandre Belloni @ 2017-12-19 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219213209.13823-1-alexandre.belloni@free-electrons.com>
The current binding for the TCB is not flexible enough for some use cases
and prevents proper utilization of all the channels.
Acked-by: Rob Herring <robh@kernel.org>
Cc: devicetree at vger.kernel.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
.../devicetree/bindings/arm/atmel-at91.txt | 32 -------------
.../devicetree/bindings/mfd/atmel-tcb.txt | 56 ++++++++++++++++++++++
2 files changed, 56 insertions(+), 32 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/atmel-tcb.txt
diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt b/Documentation/devicetree/bindings/arm/atmel-at91.txt
index 91cb8e4f2a4f..31220b54d85d 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
@@ -90,38 +90,6 @@ System Timer (ST) required properties:
Its subnodes can be:
- watchdog: compatible should be "atmel,at91rm9200-wdt"
-TC/TCLIB Timer required properties:
-- compatible: Should be "atmel,<chip>-tcb".
- <chip> can be "at91rm9200" or "at91sam9x5"
-- reg: Should contain registers location and length
-- interrupts: Should contain all interrupts for the TC block
- Note that you can specify several interrupt cells if the TC
- block has one interrupt per channel.
-- clock-names: tuple listing input clock names.
- Required elements: "t0_clk", "slow_clk"
- Optional elements: "t1_clk", "t2_clk"
-- clocks: phandles to input clocks.
-
-Examples:
-
-One interrupt per TC block:
- tcb0: timer at fff7c000 {
- compatible = "atmel,at91rm9200-tcb";
- reg = <0xfff7c000 0x100>;
- interrupts = <18 4>;
- clocks = <&tcb0_clk>;
- clock-names = "t0_clk";
- };
-
-One interrupt per TC channel in a TC block:
- tcb1: timer at fffdc000 {
- compatible = "atmel,at91rm9200-tcb";
- reg = <0xfffdc000 0x100>;
- interrupts = <26 4 27 4 28 4>;
- clocks = <&tcb1_clk>;
- clock-names = "t0_clk";
- };
-
RSTC Reset Controller required properties:
- compatible: Should be "atmel,<chip>-rstc".
<chip> can be "at91sam9260" or "at91sam9g45" or "sama5d3"
diff --git a/Documentation/devicetree/bindings/mfd/atmel-tcb.txt b/Documentation/devicetree/bindings/mfd/atmel-tcb.txt
new file mode 100644
index 000000000000..c4a83e364cb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel-tcb.txt
@@ -0,0 +1,56 @@
+* Device tree bindings for Atmel Timer Counter Blocks
+- compatible: Should be "atmel,<chip>-tcb", "simple-mfd", "syscon".
+ <chip> can be "at91rm9200" or "at91sam9x5"
+- reg: Should contain registers location and length
+- #address-cells: has to be 1
+- #size-cells: has to be 0
+- interrupts: Should contain all interrupts for the TC block
+ Note that you can specify several interrupt cells if the TC
+ block has one interrupt per channel.
+- clock-names: tuple listing input clock names.
+ Required elements: "t0_clk", "slow_clk"
+ Optional elements: "t1_clk", "t2_clk"
+- clocks: phandles to input clocks.
+
+The TCB can expose multiple subdevices:
+ * a timer
+ - compatible: Should be "atmel,tcb-timer"
+ - reg: Should contain the TCB channels to be used. If the
+ counter width is 16 bits (at91rm9200-tcb), two consecutive
+ channels are needed. Else, only one channel will be used.
+
+Examples:
+
+One interrupt per TC block:
+ tcb0: timer at fff7c000 {
+ compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xfff7c000 0x100>;
+ interrupts = <18 4>;
+ clocks = <&tcb0_clk>, <&clk32k>;
+ clock-names = "t0_clk", "slow_clk";
+
+ timer at 0 {
+ compatible = "atmel,tcb-timer";
+ reg = <0>, <1>;
+ };
+
+ timer at 2 {
+ compatible = "atmel,tcb-timer";
+ reg = <2>;
+ };
+ };
+
+One interrupt per TC channel in a TC block:
+ tcb1: timer at fffdc000 {
+ compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xfffdc000 0x100>;
+ interrupts = <26 4>, <27 4>, <28 4>;
+ clocks = <&tcb1_clk>, <&clk32k>;
+ clock-names = "t0_clk", "slow_clk";
+ };
+
+
--
2.15.1
^ permalink raw reply related
* [PATCH 00/45] Migrate TCB bindings
From: Alexandre Belloni @ 2017-12-19 21:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
As the bindings were acked by Rob a while ago [1] and I think there is
consensus on what they look like, I'm planning to apply that series for
4.16 so we get a smoother transition for the TCB driver rework.
I've simply removed the PWM binding change that I will submit with the
driver change itself.
There is also a small fix in the at91sam9261ek patch.
[1] https://patchwork.kernel.org/patch/9755341/
Cc: Antoine Aubert <a.aubert@overkiz.com>
Cc: devicetree at vger.kernel.org
Cc: Douglas Gilbert <dgilbert@interlog.com>
Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Joachim Eastwood <manabian@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Martin Reimann <martin.reimann@egnite.de>
Cc: Peter Rosin <peda@axentia.se>
Cc: Raashid Muhammed <raashidmuhammed@zilogic.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Rodolfo Giometti <giometti@linux.it>
Cc: Sergio Tanzilli <tanzilli@acmesystems.it>
Cc: Tim Schendekehl <tim.schendekehl@egnite.de>
Alexandre Belloni (45):
ARM: at91: Document new TCB bindings
ARM: dts: at91: at91rm9200: TC blocks are also simple-mfd and syscon
devices
ARM: dts: at91: at91rm9200ek: use TCB0 for timers
ARM: dts: at91: mpa1600: use TCB0 as timers
ARM: dts: at91: at91sam9260: TC blocks are also simple-mfd and syscon
devices
ARM: dts: at91: at91sam9260ek: use TCB0 as timers
ARM: dts: at91: sam9_l9260: use TCB0 as timers
ARM: dts: at91: ethernut5: use TCB0 as timers
ARM: dts: at91: foxg20: use TCB0 as timers
ARM: dts: at91: animeo_ip: use TCB0 as timers
ARM: dts: at91: kizbox: use TCB0 as timers
ARM: dts: at91: at91sam9g20ek: use TCB0 as timers
ARM: dts: at91: ge863-pro3: use TCB0 as timers
ARM: dts: at91: at91sam9261: TC blocks are also simple-mfd and syscon
devices
ARM: dts: at91: at91sam9261ek: use TCB0 as timers
ARM: dts: at91: at91sam9263: TC blocks are also simple-mfd and syscon
devices
ARM: dts: at91: at91sam9263ek: use TCB0 as timers
ARM: dts: at91: calao: use TCB0 as timers
ARM: dts: at91: at91sam9g45: TC blocks are also simple-mfd and syscon
devices
ARM: dts: at91: at91sam9m10g45ek: use TCB0 as timers
ARM: dts: at91: pm9g45: use TCB0 as timers
ARM: dts: at91: at91sam9rl: TC blocks are also simple-mfd and syscon
devices
ARM: dts: at91: at91sam9rlek: use TCB0 as timers
ARM: dts: at91: at91sam9n12: TC blocks are also simple-mfd and syscon
devices
ARM: dts: at91: at91sam9n12ek: use TCB0 as timers
ARM: dts: at91: at91sam9x5: TC blocks are also simple-mfd and syscon
devices
ARM: dts: at91: at91sam9x5cm: use TCB0 as timers
ARM: dts: at91: acme/g25: use TCB0 as timers
ARM: dts: at91: cosino: use TCB0 as timers
ARM: dts: at91: kizboxmini: use TCB0 as timers
ARM: dts: at91: sama5d3: TC blocks are also simple-mfd and syscon
devices
ARM: dts: at91: sama5d3xek: use TCB0 as timers
ARM: dts: at91: sama5d3 Xplained: use TCB0 as timers
ARM: dts: at91: kizbox2: use TCB0 as timers
ARM: dts: at91: sama5d3xek_cmp: use TCB0 as timers
ARM: dts: at91: linea/tse850-3: use TCB0 as timers
ARM: dts: at91: sama5d4: TC blocks are also simple-mfd and syscon
devices
ARM: dts: at91: sama5d4: Add TCB2
ARM: dts: at91: sama5d4ek: use TCB2 as timers
ARM: dts: at91: sama5d4 Xplained: use TCB2 as timers
ARM: dts: at91: ma5d4: use TCB2 as timers
ARM: dts: at91: vinco: use TCB2 as timers
ARM: dts: at91: sama5d2: TC blocks are also simple-mfd and syscon
devices
ARM: dts: at91: sama5d2 Xplained: use TCB0 as timers
ARM: dts: at91: sama5d27_som1_ek: use TCB0 as timers
.../devicetree/bindings/arm/atmel-at91.txt | 32 -------------
.../devicetree/bindings/mfd/atmel-tcb.txt | 56 ++++++++++++++++++++++
arch/arm/boot/dts/animeo_ip.dts | 12 +++++
arch/arm/boot/dts/at91-ariag25.dts | 12 +++++
arch/arm/boot/dts/at91-ariettag25.dts | 12 +++++
arch/arm/boot/dts/at91-cosino.dtsi | 12 +++++
arch/arm/boot/dts/at91-foxg20.dts | 12 +++++
arch/arm/boot/dts/at91-kizbox.dts | 12 +++++
arch/arm/boot/dts/at91-kizbox2.dts | 12 +++++
arch/arm/boot/dts/at91-kizboxmini.dts | 12 +++++
arch/arm/boot/dts/at91-linea.dtsi | 12 +++++
arch/arm/boot/dts/at91-qil_a9260.dts | 12 +++++
arch/arm/boot/dts/at91-sam9_l9260.dts | 12 +++++
arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 12 +++++
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 12 +++++
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 12 +++++
arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi | 12 +++++
arch/arm/boot/dts/at91-sama5d4_xplained.dts | 12 +++++
arch/arm/boot/dts/at91-sama5d4ek.dts | 12 +++++
arch/arm/boot/dts/at91-vinco.dts | 12 +++++
arch/arm/boot/dts/at91rm9200.dtsi | 8 +++-
arch/arm/boot/dts/at91rm9200ek.dts | 12 +++++
arch/arm/boot/dts/at91sam9260.dtsi | 8 +++-
arch/arm/boot/dts/at91sam9260ek.dts | 12 +++++
arch/arm/boot/dts/at91sam9261.dtsi | 4 +-
arch/arm/boot/dts/at91sam9261ek.dts | 20 ++++++++
arch/arm/boot/dts/at91sam9263.dtsi | 4 +-
arch/arm/boot/dts/at91sam9263ek.dts | 12 +++++
arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 12 +++++
arch/arm/boot/dts/at91sam9g45.dtsi | 8 +++-
arch/arm/boot/dts/at91sam9m10g45ek.dts | 12 +++++
arch/arm/boot/dts/at91sam9n12.dtsi | 8 +++-
arch/arm/boot/dts/at91sam9n12ek.dts | 12 +++++
arch/arm/boot/dts/at91sam9rl.dtsi | 4 +-
arch/arm/boot/dts/at91sam9rlek.dts | 12 +++++
arch/arm/boot/dts/at91sam9x5.dtsi | 8 +++-
arch/arm/boot/dts/at91sam9x5cm.dtsi | 12 +++++
arch/arm/boot/dts/ethernut5.dts | 12 +++++
arch/arm/boot/dts/ge863-pro3.dtsi | 12 +++++
arch/arm/boot/dts/mpa1600.dts | 12 +++++
arch/arm/boot/dts/pm9g45.dts | 12 +++++
arch/arm/boot/dts/sama5d2.dtsi | 8 +++-
arch/arm/boot/dts/sama5d3.dtsi | 4 +-
arch/arm/boot/dts/sama5d3_tcb1.dtsi | 4 +-
arch/arm/boot/dts/sama5d3xcm.dtsi | 12 +++++
arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 12 +++++
arch/arm/boot/dts/sama5d4.dtsi | 18 ++++++-
arch/arm/boot/dts/tny_a9260_common.dtsi | 12 +++++
arch/arm/boot/dts/tny_a9263.dts | 12 +++++
arch/arm/boot/dts/usb_a9260_common.dtsi | 12 +++++
arch/arm/boot/dts/usb_a9263.dts | 12 +++++
51 files changed, 575 insertions(+), 51 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/atmel-tcb.txt
--
2.15.1
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: kevans91 at ksu.edu @ 2017-12-19 21:05 UTC (permalink / raw)
To: linux-arm-kernel
Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
thermal calibration data, add node to describe it.
a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
supported in an external driver for FreeBSD.
Signed-off-by: Kyle Evans <kevans91@ksu.edu>
---
Changes in v2:
- remove bogus "From:" line in commit text; no functional change
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1 +
arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
index d69543701..e319fe5e2 100644
--- a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
+++ b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: Should be one of the following:
"allwinner,sun4i-a10-sid"
"allwinner,sun7i-a20-sid"
+ "allwinner,sun8i-a83t-sid"
"allwinner,sun8i-h3-sid"
"allwinner,sun50i-a64-sid"
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index de5119a2a..cced6e5fb 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -238,6 +238,11 @@
#size-cells = <0>;
};
+ sid: eeprom at 1c14000 {
+ compatible = "allwinner,sun8i-a83t-sid";
+ reg = <0x1c14000 0x400>;
+ };
+
usb_otg: usb at 1c19000 {
compatible = "allwinner,sun8i-a83t-musb",
"allwinner,sun8i-a33-musb";
--
2.15.1
^ permalink raw reply related
* [PATCH] arm64: Stop printing the virtual memory layout
From: Kees Cook @ 2017-12-19 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192810.22537-1-labbott@redhat.com>
On Tue, Dec 19, 2017 at 11:28 AM, Laura Abbott <labbott@redhat.com> wrote:
> Printing kernel addresses should be done in limited circumstances, mostly
> for debugging purposes. Printing out the virtual memory layout at every
> kernel bootup doesn't really fall into this category so delete the prints.
> There are other ways to get the same information.
In looking at this patch, I wonder: is there anything listed here that
is _missing_ from CONFIG_PTDUMP? I would expect all of these to
already be listed there, but I thought I'd ask...
Regardless:
Acked-by: Kees Cook <keescook@chromium.org>
-Kees
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> Follow up to my previous proposal to switch all these to %px
> ---
> arch/arm64/mm/init.c | 43 -------------------------------------------
> 1 file changed, 43 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 5960bef0170d..672094ed7e07 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -599,49 +599,6 @@ void __init mem_init(void)
>
> mem_init_print_info(NULL);
>
> -#define MLK(b, t) b, t, ((t) - (b)) >> 10
> -#define MLM(b, t) b, t, ((t) - (b)) >> 20
> -#define MLG(b, t) b, t, ((t) - (b)) >> 30
> -#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> -
> - pr_notice("Virtual kernel memory layout:\n");
> -#ifdef CONFIG_KASAN
> - pr_notice(" kasan : 0x%16lx - 0x%16lx (%6ld GB)\n",
> - MLG(KASAN_SHADOW_START, KASAN_SHADOW_END));
> -#endif
> - pr_notice(" modules : 0x%16lx - 0x%16lx (%6ld MB)\n",
> - MLM(MODULES_VADDR, MODULES_END));
> - pr_notice(" vmalloc : 0x%16lx - 0x%16lx (%6ld GB)\n",
> - MLG(VMALLOC_START, VMALLOC_END));
> - pr_notice(" .text : 0x%p" " - 0x%p" " (%6ld KB)\n",
> - MLK_ROUNDUP(_text, _etext));
> - pr_notice(" .rodata : 0x%p" " - 0x%p" " (%6ld KB)\n",
> - MLK_ROUNDUP(__start_rodata, __init_begin));
> - pr_notice(" .init : 0x%p" " - 0x%p" " (%6ld KB)\n",
> - MLK_ROUNDUP(__init_begin, __init_end));
> - pr_notice(" .data : 0x%p" " - 0x%p" " (%6ld KB)\n",
> - MLK_ROUNDUP(_sdata, _edata));
> - pr_notice(" .bss : 0x%p" " - 0x%p" " (%6ld KB)\n",
> - MLK_ROUNDUP(__bss_start, __bss_stop));
> - pr_notice(" fixed : 0x%16lx - 0x%16lx (%6ld KB)\n",
> - MLK(FIXADDR_START, FIXADDR_TOP));
> - pr_notice(" PCI I/O : 0x%16lx - 0x%16lx (%6ld MB)\n",
> - MLM(PCI_IO_START, PCI_IO_END));
> -#ifdef CONFIG_SPARSEMEM_VMEMMAP
> - pr_notice(" vmemmap : 0x%16lx - 0x%16lx (%6ld GB maximum)\n",
> - MLG(VMEMMAP_START, VMEMMAP_START + VMEMMAP_SIZE));
> - pr_notice(" 0x%16lx - 0x%16lx (%6ld MB actual)\n",
> - MLM((unsigned long)phys_to_page(memblock_start_of_DRAM()),
> - (unsigned long)virt_to_page(high_memory)));
> -#endif
> - pr_notice(" memory : 0x%16lx - 0x%16lx (%6ld MB)\n",
> - MLM(__phys_to_virt(memblock_start_of_DRAM()),
> - (unsigned long)high_memory));
> -
> -#undef MLK
> -#undef MLM
> -#undef MLK_ROUNDUP
> -
> /*
> * Check boundaries twice: Some fundamental inconsistencies can be
> * detected at build time already.
> --
> 2.14.3
>
--
Kees Cook
Pixel Security
^ permalink raw reply
* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Andrew Lunn @ 2017-12-19 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKddg82waiapD8JzH0pCsWVTE2iT0LFz7PCYrrDDpXqmbw@mail.gmail.com>
> Of course! v2 will not have such problem, I've been waiting however
> for the feedback about the ACPI representation. Anyway, I'm strongly
> leaning towards using _ADR/_CID objects in PHY's nodes for ACPI, so
> maybe I'll just issue the v2 in order to push the discussion a bit
> forward.
Hi Marcin
I know ~0 about ACPI. But what seems to be missing for me is
documentation. You are defining a ABI here, which all future MDIO
busses, PHYs, and to some extent Ethernet switches need to follow. So
i would expect this to be documented somewhere.
How does documentation work in the ACPI world?
Andrew
^ permalink raw reply
* [PATCH v8 3/9] KVM: arm/arm64: Don't cache the timer IRQ level
From: Christoffer Dall @ 2017-12-19 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <517ead96-a689-d6f6-564f-67b1cd020daf@arm.com>
On Tue, Dec 19, 2017 at 02:17:38PM +0000, Julien Thierry wrote:
> Hi Christoffer,
>
> A few nits in the commit message.
>
> On 13/12/17 10:45, Christoffer Dall wrote:
> >The timer was modeled after a strict idea of modelling an interrupt line
>
> nit: modelling (also, modeled after a strict idea of modelling?)
>
Yes, I model the modelling of models of modeled timers. Is that not
clear? ;)
> >level in software, meaning that only transitions in the level needed to
>
> s/needed/need/ ?
>
ack
> >be reported to the VGIC. This works well for the timer, because the
> >arch timer code is in complete control of the device and can track the
> >transitions of the line.
> >
> >However, as we are about to support using the HW bit in the VGIC not
> >just for the timer, but also for VFIO which cannot track transitions of
> >the interrupt line, we have to decide on an interface for level
> >triggered mapped interrupts to the GIC, which both the timer and VFIO
>
> "level triggered interrupts mapped to the GIC" ?
>
an interface to the GIC for level ...
My writing here is really crap. Thanks for pointing that out.
> >can use.
> >
> >VFIO only sees an asserting transition of the physical interrupt line,
> >and tells the VGIC when that happens. That means that part of the
> >interrupt flow is offloaded to the hardware.
> >
> >To use the same interface for VFIO devices and the timer, we therefore
> >have to change the timer (we cannot change VFIO because it doesn't know
> >the details of the device it is assigning to a VM).
> >
> >Luckily, changing the timer is simple, we just need to stop 'caching'
> >the line level, but instead let the VGIC know the state of the timer
> >every time there is a potential change in the line level, and when the
> >line level should be asserted from the timer ISR. The VGIC can ignore
> >extra notifications using its validate mechanism.
> >
> >Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> >Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>
> Reviewed-by: Julien Thierry <julien.thierry@arm.com>
>
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v8 9/9] KVM: arm/arm64: Update timer and forwarded irq documentation
From: Marc Zyngier @ 2017-12-19 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219202954.GC5380@cbox>
On Tue, 19 Dec 2017 21:29:54 +0100
Christoffer Dall <christoffer.dall@linaro.org> wrote:
> On Wed, Dec 13, 2017 at 08:15:10PM +0000, Marc Zyngier wrote:
> > On Wed, 13 Dec 2017 10:46:02 +0000,
> > Christoffer Dall wrote:
> > >
> > > Now when we've reworked how mapped level-triggered interrupts are
> > > processed for the timer interrupts, we update the documentation
> > > correspondingly.
> >
> > Seems like the documentation is more out of date than we thought, see
> > below.
> >
>
> Indeed. And I wondered if we should just nuke this file. The reason I
> added it originally was that the concept of "never taking the interrupt"
> was confusing to most, and we had to explain it several times over, but
> perhaps it's really not needed anymore and we should let people read the
> code instead?
Suits me (maintaining documentation is hard). I suggest we delete it
and write the perfect explanation once KVM is completely done...
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-19 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219203055.GF7997@codeaurora.org>
On 12/19/2017 02:30 PM, Stephen Boyd wrote:
> Yeah I wouldn't do that. I'm not trying to avoid allocating the
> array anymore. Dynamically sized arrays on the stack are not a
> great idea in the kernel where we have limited stack sizes.
So do you just want to see a v11 that drops support for QCOM8001?
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Stephen Boyd @ 2017-12-19 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1f6b198f-d277-51dd-09ad-e1d751d5c1fa@codeaurora.org>
On 12/19, Timur Tabi wrote:
> On 12/18/2017 08:39 PM, Stephen Boyd wrote:
> >+ for (i = 0, j = 0; i < num_gpios; i++) {
> > pins[i].number = i;
> >- pins[i].name = names[i];
> >+ groups[i].pins = &pins[i].number;
> >+
> >+ /* Only expose GPIOs that are available */
> >+ if (gpios && gpios[j] != i)
> >+ continue;
>
> I don't know if I would say this is an improvement. For one thing,
> QCOM8001 systems are deprecated and don't really exist any more. At
> the time I originally wrote this patch, they were still in the wild,
> but they're all gone now. So it's no longer efficient to treat
> QCOM8001 as the default case. This means that the for-loop will
> iterate over the full range now, instead of the partial range that
> it does with my v10 patch.
>
> If I post another version of this patch, I'm just going to remove
> support for QCOM8001.
That sounds good too. The diff was really noisy because all the
foo[i] became foo[gpio] which causes the diff to increase for no
real purpose. My patch was rewriting that stuff so it doesn't
come into the diff and we can concentrate on what's actually
changing. We already iterate over the full range to fill in the
two fields anyway, so I'm not sure what you're getting at with
your for-loop comment. Seems like a micro-optimization on probe
that probably isn't going to be noticed.
>
> If you want to avoid kmalloc'ing the GPIOs array, we can put it on
> the stack with a dynamic size, since it will be no more than
> MAX_GPIOS * 2 (i.e. 512) bytes in size.
>
> u16 gpios[avail_gpios];
>
> It would be a little hackish since it needs to be defined at the
> beginning of a code block, so I would probably put into its own
> function, but I still fail to see what's wrong with using kmalloc to
> allocate that array for short-term use temporarily.
>
Yeah I wouldn't do that. I'm not trying to avoid allocating the
array anymore. Dynamically sized arrays on the stack are not a
great idea in the kernel where we have limited stack sizes.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v8 9/9] KVM: arm/arm64: Update timer and forwarded irq documentation
From: Christoffer Dall @ 2017-12-19 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86efnywfjl.wl-marc.zyngier@arm.com>
On Wed, Dec 13, 2017 at 08:15:10PM +0000, Marc Zyngier wrote:
> On Wed, 13 Dec 2017 10:46:02 +0000,
> Christoffer Dall wrote:
> >
> > Now when we've reworked how mapped level-triggered interrupts are
> > processed for the timer interrupts, we update the documentation
> > correspondingly.
>
> Seems like the documentation is more out of date than we thought, see
> below.
>
Indeed. And I wondered if we should just nuke this file. The reason I
added it originally was that the concept of "never taking the interrupt"
was confusing to most, and we had to explain it several times over, but
perhaps it's really not needed anymore and we should let people read the
code instead?
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt | 50 ++++++++++------------
> > 1 file changed, 23 insertions(+), 27 deletions(-)
> >
> > diff --git a/Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt b/Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt
> > index 38bca2835278..f68c7d95a341 100644
> > --- a/Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt
> > +++ b/Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt
> > @@ -7,9 +7,10 @@ allowing software to inject virtual interrupts to a VM, which the guest
> > OS sees as regular interrupts. The code is famously known as the VGIC.
> >
> > Some of these virtual interrupts, however, correspond to physical
> > -interrupts from real physical devices. One example could be the
> > -architected timer, which itself supports virtualization, and therefore
> > -lets a guest OS program the hardware device directly to raise an
> > +interrupts from real physical devices. One example could be the ARM
> > +Generic Timers (also known as the "architected timers"), which are
> > +directly assigned to a VM while it's running, and therefore
> > +makes it possible for guest OSes to program the timers directly to raise an
> > interrupt at some point in time. When such an interrupt is raised, the
> > host OS initially handles the interrupt and must somehow signal this
> > event as a virtual interrupt to the guest. Another example could be a
> > @@ -37,7 +38,7 @@ inactive.
> >
> > The LRs include an extra bit, called the HW bit. When this bit is set,
> > KVM must also program an additional field in the LR, the physical IRQ
> > -number, to link the virtual with the physical IRQ.
> > +number, to link the virtual and physical IRQs together.
> >
> > When the HW bit is set, KVM must EITHER set the Pending OR the Active
> > bit, never both at the same time.
> > @@ -59,21 +60,21 @@ The state of forwarded physical interrupts is managed in the following way:
> > - LR.Pending will stay set as long as the guest has not acked the interrupt.
> > - LR.Pending transitions to LR.Active on the guest read of the IAR, as
> > expected.
> > - - On guest EOI, the *physical distributor* active bit gets cleared,
> > + - On guest deactivate, the *physical distributor* active bit gets cleared,
> > but the LR.Active is left untouched (set).
>
> Is this true? I seem to remember that we established it wasn't (back
> when we redesigned the vgic). Certainly, the current code relies on
> the Active bit being cleared in the LR as well as in the physical
> distributor.
>
No, you're right, it' crap.
> > - KVM clears the LR on VM exits when the physical distributor
> > active state has been cleared.
>
> And this isn't either, if my above assertion stands.
>
Right again.
> >
> > (*): The host handling is slightly more complicated. For some forwarded
> > -interrupts (shared), KVM directly sets the active state on the physical
> > -distributor before entering the guest, because the interrupt is never actually
> > -handled on the host (see details on the timer as an example below). For other
> > -forwarded interrupts (non-shared) the host does not deactivate the interrupt
> > -when the host ISR completes, but leaves the interrupt active until the guest
> > -deactivates it. Leaving the interrupt active is allowed, because Linux
> > -configures the physical GIC with EOIMode=1, which causes EOI operations to
> > -perform a priority drop allowing the GIC to receive other interrupts of the
> > -default priority.
> > +interrupts (shared), in some cases, KVM directly sets the active state
> > +on the physical distributor before entering the guest, because the
> > +interrupt is never actually handled on the host (see details on the
> > +timer as an example below). In other cases, the host does not
>
> This isn't true either. We now handle the timer interrupt on the host.
>
And again. I've rewritten this.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH net 0/3] Few mvneta fixes
From: Arnd Bergmann @ 2017-12-19 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219165947.28516-1-gregory.clement@free-electrons.com>
On Tue, Dec 19, 2017 at 5:59 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Hello,
>
> here it is a small series of fixes found on the mvneta driver. They
> had been already used in the vendor kernel and are now ported to
> mainline.
Does one of the patches look like it addresses the rare Oops we discussed on
#kernelci this morning?
https://storage.kernelci.org/stable/linux-4.9.y/v4.9.70/arm/mvebu_v7_defconfig/lab-free-electrons/boot-armada-375-db.html
Arnd
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add sid for a83t
From: kevans91 at ksu.edu @ 2017-12-19 20:11 UTC (permalink / raw)
To: linux-arm-kernel
From: Kyle Evans <kevans91@ksu.edu>
Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
thermal calibration data, add node to describe it.
a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
supported in an external driver for FreeBSD.
Signed-off-by: Kyle Evans <kevans91@ksu.edu>
---
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1 +
arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
index d69543701..e319fe5e2 100644
--- a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
+++ b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: Should be one of the following:
"allwinner,sun4i-a10-sid"
"allwinner,sun7i-a20-sid"
+ "allwinner,sun8i-a83t-sid"
"allwinner,sun8i-h3-sid"
"allwinner,sun50i-a64-sid"
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index de5119a2a..cced6e5fb 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -238,6 +238,11 @@
#size-cells = <0>;
};
+ sid: eeprom at 1c14000 {
+ compatible = "allwinner,sun8i-a83t-sid";
+ reg = <0x1c14000 0x400>;
+ };
+
usb_otg: usb at 1c19000 {
compatible = "allwinner,sun8i-a83t-musb",
"allwinner,sun8i-a33-musb";
--
2.15.1
^ permalink raw reply related
* next/master boot: 270 boots: 35 failed, 213 passed with 20 offline, 2 untried/unknown (next-20171207)
From: Stephen Boyd @ 2017-12-19 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11a4d79d-73a5-5e98-c83f-f5e47bcfcdf2@samsung.com>
On 12/11, Marek Szyprowski wrote:
> Hi Stephen,
>
> On 2017-12-08 17:59, Stephen Boyd wrote:
> >On 12/08, Marek Szyprowski wrote:
> >>On 2017-12-08 13:33, Krzysztof Kozlowski wrote:
> >>>On Fri, Dec 8, 2017 at 1:27 PM, Mark Brown <broonie@kernel.org> wrote:
> >>>>On Fri, Dec 08, 2017 at 12:20:07PM +0000, Mark Brown wrote:
> >>>>>On Thu, Dec 07, 2017 at 03:54:47PM -0800, kernelci.org bot wrote:
> >>>>>
> >>>>>Today's -next failed to boot on peach-pi:
> >>>>>
> >>>>>> exynos_defconfig:
> >>>>>> exynos5800-peach-pi:
> >>>>>> lab-collabora: new failure (last pass: next-20171205)
> >>>>>with details at https://kernelci.org/boot/id/5a2a2e7859b5141bc2afa17c/
> >>>>>(including logs and comparisons with other boots, the last good boot was
> >>>>>Wednesday). It looks like it hangs somewhere late on in boot, the last
> >>>>>output on the console is:
> >>>>>
> >>>>>[ 4.827139] smsc95xx 3-1.1:1.0 eth0: register 'smsc95xx' at usb-xhci-hcd.3.auto-1.1, smsc95xx USB 2.0 Ethernet, 94:eb:2c:00:03:c0
> >>>>>[ 5.781037] dma-pl330 3880000.adma: Loaded driver for PL330 DMAC-241330
> >>>>>[ 5.786247] dma-pl330 3880000.adma: DBUFF-4x8bytes Num_Chans-6 Num_Peri-16 Num_Events-6
> >>>>>[ 5.819200] dma-pl330 3880000.adma: PM domain MAU will not be powered off
> >>>>>[ 64.529228] random: crng init done
> >>>>>
> >>>>>and there's failures earlier to instantiate the display.
> >>>>I just noticed that further up the log there's a lockdep splat with a
> >>>>conflict between the genpd and clock API locking - an ABBA issue with
> >>>>genpd->mlock and the clock API prepare_lock.
> >>>+Cc Marek Szyprowski,
> >>>
> >>>The lockdep issue and display failures (including regulator warning)
> >>>were present for some time. They also appear in boot log for
> >>>next-20171206 (https://storage.kernelci.org/next/master/next-20171206/arm/exynos_defconfig/lab-collabora/boot-exynos5800-peach-pi.html).
> >>>The difference is that 20171208 hangs on "random: crng init done"
> >>>which did not appear before at all.
> >I haven't looked at the lockdep splat yet, but is that happening
> >because of runtime PM usage by the clk framework?
>
> This is a false positive. The deplock doesn't distinguish each
> domain instance.
> Only some instances of exynos power domains use clocks (as an old
> workaround of
> the lack possibility to integrate proper clock rate/topology
> restoration after
> power off/on cycle in the clock provider driver).
>
> Those clock controllers, which implements runtime pm, are assigned to power
> domain, which doesn't touch clocks at all.
>
> I still have no idea how to fix the code to make deplock happy.
>
Right. Once lockdep complains lockdep turns itself off, so we
lose the ability to detect other problems. Even if it's a false
positive, it's a potential problem on some device so it's
concerning that runtime PM usage from clk framework has created
this potential problem.
Is it possible to remove the clk operations from the exynos power
domains? You say it's to deal with the lack of rate/topology
restoration so maybe it can be changed. That will at least allow
lockdep to continue working here and detect the "real" deadlock
here. Otherwise, do we need to revert runtime PM for clk
framework and back out all the Samsung changes on top of that? If
we need to do that, we need to do it soon.
We'll need to think about how to resolve the cross-subsystem
locking problem regardless. We definitely want to have genpd be
able to do CCF things, and CCF to use runtime PM and genpds too.
It seems that we have a classic AB-BA deadlock potential between
the clk prepare lock and the genpd domain mutex. Both frameworks
are holding a mutex across the operations of their providers
(either clk_ops or genpd power_on/off) so we can't have the CCF
call genpd things and genpd call CCF things or lockdep will
complain. I was worried about runtime PM usage by CCF causing
this problem, but I missed that genpd was behind runtime PM so I
didn't consider the locks in that part of the chain. Ugh.
Maybe we can have runtime PM things done outside of the prepare
lock in CCF, that way we aren't holding any locks that genpd may
need to use. That would fix the problem, but would expose us to
clk tree topology changes happening while we enable runtime PM
for clks. It would be great if we could drop all framework level
locks when we call into provider drivers. I'm not sure how to do
that yet, but that's probably the end goal.
Anyway, this needs some thought to figure out how to redesign the
CCF locking scheme so this problem doesn't exist.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: sunxi: sun9i-mmc: Implement reset callback for reset controls
From: Michael Turquette @ 2017-12-19 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219083228.mima36idnmhmogdy@flea.lan>
Quoting Maxime Ripard (2017-12-19 00:32:28)
> On Mon, Dec 18, 2017 at 01:07:09PM -0800, Stephen Boyd wrote:
> > On 12/18, Chen-Yu Tsai wrote:
> > > Our MMC host driver now issues a reset, instead of just deasserting
> > > the reset control, since commit c34eda69ad4c ("mmc: sunxi: Reset the
> > > device at probe time"). The sun9i-mmc clock driver does not support
> > > this, and will fail, which results in MMC not probing.
> > >
> > > This patch implements the reset callback by asserting the reset control,
> > > then deasserting it after a small delay.
> > >
> > > Fixes: 7a6fca879f59 ("clk: sunxi: Add driver for A80 MMC config clocks/resets")
> > > Cc: <stable@vger.kernel.org> # 4.14.x
> > > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> > > ---
> >
> > Did you want us to pick this up into clk-fixes? It seems to be
> > causing MMC to not work for some time? That sounds annoying
> > enough.
>
> That would be great, thanks!
Applied to clk-fixes.
Regards,
Mike
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] usb: musb: un-break davinci glue layer
From: Bin Liu @ 2017-12-19 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CF323D845261FD4F9B1E997381250334E344CBEB@maildb.hanover.local>
On Tue, Dec 19, 2017 at 05:33:14PM +0000, Alejandro Mery wrote:
> Hi Bin,
>
> On 19/12/17 17:22, Bin Liu wrote:
> > Hi Alejandro,
> >
> > On Fri, Dec 08, 2017 at 07:23:54PM +0000, Alejandro Mery wrote:
> >> MUSB's davinci glue was made to depend on BROKEN by Felipe Balbi back in
> >> 2013 because of lack of active development. needed changes were actually trivial
> >>
> >> Fixes: 787f5627bec8 (usb: musb: make davinci and da8xx glues depend on BROKEN)
> >> Signed-off-by: Alejandro Mery <amery@hanoverdisplays.com>
> > Thanks for the effort to re-enable this driver. But due to lack of
> > development, other than the phy and fifo mode which you try to fix with
> > these two patches, the driver still doesn't fit in the current driver
> > framework, for example,
> >
> > - the driver depends on mach/ header for CPU and board type;
> > - clk control is not separated;
> > - gpio control vbus should use extcon driver;
> I'll try to fix these issues but it will take a while. I'm still
> struggling to get USB working at all on the DM365 EVM
Thanks for the effort.
>
> >
> > So I feel it is not ready to un-broken it yet, unless others have
> > different opinion.
> >
> > But I could take these two patches if not remove BROKEN from Kconfig.
>
> do you want a v2 for that?
That will be great!
Thanks,
-Bin.
^ permalink raw reply
* [PATCH] arm64: Stop printing the virtual memory layout
From: Laura Abbott @ 2017-12-19 19:28 UTC (permalink / raw)
To: linux-arm-kernel
Printing kernel addresses should be done in limited circumstances, mostly
for debugging purposes. Printing out the virtual memory layout at every
kernel bootup doesn't really fall into this category so delete the prints.
There are other ways to get the same information.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
Follow up to my previous proposal to switch all these to %px
---
arch/arm64/mm/init.c | 43 -------------------------------------------
1 file changed, 43 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5960bef0170d..672094ed7e07 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -599,49 +599,6 @@ void __init mem_init(void)
mem_init_print_info(NULL);
-#define MLK(b, t) b, t, ((t) - (b)) >> 10
-#define MLM(b, t) b, t, ((t) - (b)) >> 20
-#define MLG(b, t) b, t, ((t) - (b)) >> 30
-#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
-
- pr_notice("Virtual kernel memory layout:\n");
-#ifdef CONFIG_KASAN
- pr_notice(" kasan : 0x%16lx - 0x%16lx (%6ld GB)\n",
- MLG(KASAN_SHADOW_START, KASAN_SHADOW_END));
-#endif
- pr_notice(" modules : 0x%16lx - 0x%16lx (%6ld MB)\n",
- MLM(MODULES_VADDR, MODULES_END));
- pr_notice(" vmalloc : 0x%16lx - 0x%16lx (%6ld GB)\n",
- MLG(VMALLOC_START, VMALLOC_END));
- pr_notice(" .text : 0x%p" " - 0x%p" " (%6ld KB)\n",
- MLK_ROUNDUP(_text, _etext));
- pr_notice(" .rodata : 0x%p" " - 0x%p" " (%6ld KB)\n",
- MLK_ROUNDUP(__start_rodata, __init_begin));
- pr_notice(" .init : 0x%p" " - 0x%p" " (%6ld KB)\n",
- MLK_ROUNDUP(__init_begin, __init_end));
- pr_notice(" .data : 0x%p" " - 0x%p" " (%6ld KB)\n",
- MLK_ROUNDUP(_sdata, _edata));
- pr_notice(" .bss : 0x%p" " - 0x%p" " (%6ld KB)\n",
- MLK_ROUNDUP(__bss_start, __bss_stop));
- pr_notice(" fixed : 0x%16lx - 0x%16lx (%6ld KB)\n",
- MLK(FIXADDR_START, FIXADDR_TOP));
- pr_notice(" PCI I/O : 0x%16lx - 0x%16lx (%6ld MB)\n",
- MLM(PCI_IO_START, PCI_IO_END));
-#ifdef CONFIG_SPARSEMEM_VMEMMAP
- pr_notice(" vmemmap : 0x%16lx - 0x%16lx (%6ld GB maximum)\n",
- MLG(VMEMMAP_START, VMEMMAP_START + VMEMMAP_SIZE));
- pr_notice(" 0x%16lx - 0x%16lx (%6ld MB actual)\n",
- MLM((unsigned long)phys_to_page(memblock_start_of_DRAM()),
- (unsigned long)virt_to_page(high_memory)));
-#endif
- pr_notice(" memory : 0x%16lx - 0x%16lx (%6ld MB)\n",
- MLM(__phys_to_virt(memblock_start_of_DRAM()),
- (unsigned long)high_memory));
-
-#undef MLK
-#undef MLM
-#undef MLK_ROUNDUP
-
/*
* Check boundaries twice: Some fundamental inconsistencies can be
* detected at build time already.
--
2.14.3
^ permalink raw reply related
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-19 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219023935.GA17456@codeaurora.org>
On 12/18/2017 08:39 PM, Stephen Boyd wrote:
> + for (i = 0, j = 0; i < num_gpios; i++) {
> pins[i].number = i;
> - pins[i].name = names[i];
> + groups[i].pins = &pins[i].number;
> +
> + /* Only expose GPIOs that are available */
> + if (gpios && gpios[j] != i)
> + continue;
I don't know if I would say this is an improvement. For one thing,
QCOM8001 systems are deprecated and don't really exist any more. At the
time I originally wrote this patch, they were still in the wild, but
they're all gone now. So it's no longer efficient to treat QCOM8001 as
the default case. This means that the for-loop will iterate over the
full range now, instead of the partial range that it does with my v10 patch.
If I post another version of this patch, I'm just going to remove
support for QCOM8001.
If you want to avoid kmalloc'ing the GPIOs array, we can put it on the
stack with a dynamic size, since it will be no more than MAX_GPIOS * 2
(i.e. 512) bytes in size.
u16 gpios[avail_gpios];
It would be a little hackish since it needs to be defined at the
beginning of a code block, so I would probably put into its own
function, but I still fail to see what's wrong with using kmalloc to
allocate that array for short-term use temporarily.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [-next PATCH 0/4] sysfs and DEVICE_ATTR_<foo>
From: Corey Minyard @ 2017-12-19 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1513706701.git.joe@perches.com>
On 12/19/2017 12:15 PM, Joe Perches wrote:
> drivers/char/ipmi/ipmi_msghandler.c | 17 +++---
For ipmi:
Acked-by: Corey Minyard <cminyard@mvista.com>
^ permalink raw reply
* [PATCH v2 9/9] soc: brcmstb: biuctrl: Move to early_initcall
From: Florian Fainelli @ 2017-12-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
Being called during early_initcall() is early enough that it occurs
before SMP initialization, which is all we care about for the Bus
Interface Unit configuration.
This solves lack of BIU initialization on ARM64 platforms where we do
not have an anchor where to put the BIU initialization (since there are
no machine descriptors).
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mach-bcm/brcmstb.c | 2 --
drivers/soc/bcm/brcmstb/biuctrl.c | 6 ++++--
include/linux/soc/brcmstb/brcmstb.h | 6 ------
3 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-bcm/brcmstb.c b/arch/arm/mach-bcm/brcmstb.c
index 07e3a86c6466..5f127d5f1045 100644
--- a/arch/arm/mach-bcm/brcmstb.c
+++ b/arch/arm/mach-bcm/brcmstb.c
@@ -14,7 +14,6 @@
#include <linux/init.h>
#include <linux/irqchip.h>
#include <linux/of_platform.h>
-#include <linux/soc/brcmstb/brcmstb.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -38,7 +37,6 @@ u32 brcmstb_uart_config[3] = {
static void __init brcmstb_init_irq(void)
{
irqchip_init();
- brcmstb_biuctrl_init();
}
static const char *const brcmstb_match[] __initconst = {
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index dd45bbfe64dd..2b23ae7b5e9b 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -240,7 +240,7 @@ static struct syscore_ops brcmstb_cpu_credit_syscore_ops = {
#endif
-void __init brcmstb_biuctrl_init(void)
+static int __init brcmstb_biuctrl_init(void)
{
int ret;
@@ -249,11 +249,13 @@ void __init brcmstb_biuctrl_init(void)
ret = mcp_write_pairing_set();
if (ret) {
pr_err("MCP: Unable to disable write pairing!\n");
- return;
+ return ret;
}
mcp_b53_set();
#ifdef CONFIG_PM_SLEEP
register_syscore_ops(&brcmstb_cpu_credit_syscore_ops);
#endif
+ return 0;
}
+early_initcall(brcmstb_biuctrl_init);
diff --git a/include/linux/soc/brcmstb/brcmstb.h b/include/linux/soc/brcmstb/brcmstb.h
index 12e548938bbb..8e884e0dda0a 100644
--- a/include/linux/soc/brcmstb/brcmstb.h
+++ b/include/linux/soc/brcmstb/brcmstb.h
@@ -13,12 +13,6 @@ static inline u32 BRCM_REV(u32 reg)
}
/*
- * Bus Interface Unit control register setup, must happen early during boot,
- * before SMP is brought up, called by machine entry point.
- */
-void brcmstb_biuctrl_init(void);
-
-/*
* Helper functions for getting family or product id from the
* SoC driver.
*/
--
2.9.3
^ permalink raw reply related
* [PATCH v2 8/9] soc: brcmstb: Split initialization
From: Florian Fainelli @ 2017-12-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
We may need access to family_id and product_id fairly early on boot for
other parts of the code (e.g: biuctrl.c), so split the initialization
between an early_init() and an arch_initcall() which allows us to do
that.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/soc/bcm/brcmstb/common.c | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/soc/bcm/brcmstb/common.c b/drivers/soc/bcm/brcmstb/common.c
index a71730da6385..781ada62d0a3 100644
--- a/drivers/soc/bcm/brcmstb/common.c
+++ b/drivers/soc/bcm/brcmstb/common.c
@@ -66,13 +66,10 @@ static const struct of_device_id sun_top_ctrl_match[] = {
{ }
};
-static int __init brcmstb_soc_device_init(void)
+static int __init brcmstb_soc_device_early_init(void)
{
- struct soc_device_attribute *soc_dev_attr;
- struct soc_device *soc_dev;
struct device_node *sun_top_ctrl;
void __iomem *sun_top_ctrl_base;
- int ret = 0;
sun_top_ctrl = of_find_matching_node(NULL, sun_top_ctrl_match);
if (!sun_top_ctrl)
@@ -84,12 +81,19 @@ static int __init brcmstb_soc_device_init(void)
family_id = readl(sun_top_ctrl_base);
product_id = readl(sun_top_ctrl_base + 0x4);
+ iounmap(sun_top_ctrl_base);
+ return 0;
+}
+early_initcall(brcmstb_soc_device_early_init);
+
+static int __init brcmstb_soc_device_init(void)
+{
+ struct soc_device_attribute *soc_dev_attr;
+ struct soc_device *soc_dev;
soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
- if (!soc_dev_attr) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!soc_dev_attr)
+ return -ENOMEM;
soc_dev_attr->family = kasprintf(GFP_KERNEL, "%x",
family_id >> 28 ?
@@ -107,14 +111,9 @@ static int __init brcmstb_soc_device_init(void)
kfree(soc_dev_attr->soc_id);
kfree(soc_dev_attr->revision);
kfree(soc_dev_attr);
- ret = -ENODEV;
- goto out;
+ return -ENOMEM;
}
return 0;
-
-out:
- iounmap(sun_top_ctrl_base);
- return ret;
}
arch_initcall(brcmstb_soc_device_init);
--
2.9.3
^ permalink raw reply related
* [PATCH v2 7/9] soc: brcmstb: biuctrl: Fine tune B53 MCP interface settings
From: Florian Fainelli @ 2017-12-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
In order to achieve expected MCP bus throughput on 3 particular chips:
7268, 7271 and 7278, do the appropriate programming of the MCP
interface: increase number of MCP write credits, turn on write-back
throttling when present.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/soc/bcm/brcmstb/biuctrl.c | 76 +++++++++++++++++++++++++++++++++++++++
1 file changed, 76 insertions(+)
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index d498f9db01ab..dd45bbfe64dd 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -22,6 +22,18 @@
#include <linux/soc/brcmstb/brcmstb.h>
#define CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK 0x70000000
+#define CPU_CREDIT_REG_MCPx_READ_CRED_MASK 0xf
+#define CPU_CREDIT_REG_MCPx_WRITE_CRED_MASK 0xf
+#define CPU_CREDIT_REG_MCPx_READ_CRED_SHIFT(x) ((x) * 8)
+#define CPU_CREDIT_REG_MCPx_WRITE_CRED_SHIFT(x) (((x) * 8) + 4)
+
+#define CPU_MCP_FLOW_REG_MCPx_RDBUFF_CRED_SHIFT(x) ((x) * 8)
+#define CPU_MCP_FLOW_REG_MCPx_RDBUFF_CRED_MASK 0xff
+
+#define CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_THRESHOLD_MASK 0xf
+#define CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_MASK 0xf
+#define CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_SHIFT 4
+#define CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_ENABLE BIT(8)
static void __iomem *cpubiuctrl_base;
static bool mcp_wr_pairing_en;
@@ -59,6 +71,13 @@ static const int b15_cpubiuctrl_regs[] = {
[CPU_WRITEBACK_CTRL_REG] = -1,
};
+/* Odd cases, e.g: 7260 */
+static const int b53_cpubiuctrl_no_wb_regs[] = {
+ [CPU_CREDIT_REG] = 0x0b0,
+ [CPU_MCP_FLOW_REG] = 0x0b4,
+ [CPU_WRITEBACK_CTRL_REG] = -1,
+};
+
static const int b53_cpubiuctrl_regs[] = {
[CPU_CREDIT_REG] = 0x0b0,
[CPU_MCP_FLOW_REG] = 0x0b4,
@@ -90,6 +109,59 @@ static int __init mcp_write_pairing_set(void)
return 0;
}
+static const u32 b53_mach_compat[] = {
+ 0x7268,
+ 0x7271,
+ 0x7278,
+};
+
+static void __init mcp_b53_set(void)
+{
+ unsigned int i;
+ u32 reg;
+
+ reg = brcmstb_get_family_id();
+
+ for (i = 0; i < ARRAY_SIZE(b53_mach_compat); i++) {
+ if (BRCM_ID(reg) == b53_mach_compat[i])
+ break;
+ }
+
+ if (i == ARRAY_SIZE(b53_mach_compat))
+ return;
+
+ /* Set all 3 MCP interfaces to 8 credits */
+ reg = cbc_readl(CPU_CREDIT_REG);
+ for (i = 0; i < 3; i++) {
+ reg &= ~(CPU_CREDIT_REG_MCPx_WRITE_CRED_MASK <<
+ CPU_CREDIT_REG_MCPx_WRITE_CRED_SHIFT(i));
+ reg &= ~(CPU_CREDIT_REG_MCPx_READ_CRED_MASK <<
+ CPU_CREDIT_REG_MCPx_READ_CRED_SHIFT(i));
+ reg |= 8 << CPU_CREDIT_REG_MCPx_WRITE_CRED_SHIFT(i);
+ reg |= 8 << CPU_CREDIT_REG_MCPx_READ_CRED_SHIFT(i);
+ }
+ cbc_writel(reg, CPU_CREDIT_REG);
+
+ /* Max out the number of in-flight Jwords reads on the MCP interface */
+ reg = cbc_readl(CPU_MCP_FLOW_REG);
+ for (i = 0; i < 3; i++)
+ reg |= CPU_MCP_FLOW_REG_MCPx_RDBUFF_CRED_MASK <<
+ CPU_MCP_FLOW_REG_MCPx_RDBUFF_CRED_SHIFT(i);
+ cbc_writel(reg, CPU_MCP_FLOW_REG);
+
+ /* Enable writeback throttling, set timeout to 128 cycles, 256 cycles
+ * threshold
+ */
+ reg = cbc_readl(CPU_WRITEBACK_CTRL_REG);
+ reg |= CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_ENABLE;
+ reg &= ~CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_THRESHOLD_MASK;
+ reg &= ~(CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_MASK <<
+ CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_SHIFT);
+ reg |= 8;
+ reg |= 7 << CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_SHIFT;
+ cbc_writel(reg, CPU_WRITEBACK_CTRL_REG);
+}
+
static int __init setup_hifcpubiuctrl_regs(void)
{
struct device_node *np, *cpu_dn;
@@ -126,6 +198,9 @@ static int __init setup_hifcpubiuctrl_regs(void)
ret = -EINVAL;
}
of_node_put(cpu_dn);
+
+ if (BRCM_ID(brcmstb_get_family_id()) == 0x7260)
+ cpubiuctrl_regs = b53_cpubiuctrl_no_wb_regs;
out:
of_node_put(np);
return ret;
@@ -177,6 +252,7 @@ void __init brcmstb_biuctrl_init(void)
return;
}
+ mcp_b53_set();
#ifdef CONFIG_PM_SLEEP
register_syscore_ops(&brcmstb_cpu_credit_syscore_ops);
#endif
--
2.9.3
^ 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