* [PATCH V7 07/12] clk: sprd: add adjustable pll support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-8-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> Introduced a common adjustable pll clock driver for Spreadtrum SoCs.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 06/12] clk: sprd: add composite clock support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-7-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This patch introduced composite driver for Spreadtrum's SoCs. The
> functions of this composite clock simply consist of divider and
> mux clocks.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 05/12] clk: sprd: add divider clock support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-6-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This is a feature that can also be found in sprd composite clocks,
> provide a bunch of helpers that can be reused later on.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 04/12] clk: sprd: add mux clock support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-5-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This patch adds clock multiplexor support for Spreadtrum platforms,
> the mux clocks also can be found in sprd composite clocks, so
> provides two helpers that can be reused later on.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 03/12] clk: sprd: add gate clock support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-4-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> Some clocks on the Spreadtrum's SoCs are just simple gates. Add
> support for those clocks.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 02/12] clk: sprd: Add common infrastructure
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-3-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> Added Spreadtrum's clock driver framework together with common
> structures and interface functions.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 01/12] drivers: move clock common macros out from vendor directories
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-2-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> These macros are used by more than one SoC vendor platforms, avoid to
> have many copies of these code, this patch moves them to the common
> header file which every clock drivers can access to.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6
From: Rob Herring @ 2017-12-21 22:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220134710.64479-2-jan.tuerk@emtrion.com>
On Wed, Dec 20, 2017 at 02:47:01PM +0100, jan.tuerk at emtrion.com wrote:
> From: Jan Tuerk <jan.tuerk@emtrion.com>
>
> The Emerging Display Technology ETM0700G0BDH6 is exactly
> the same display as the ETM0700G0DH6, exept the pixelclock
> polarity. Therefore re-use the ETM0700G0DH6 modes. It is
> used by default on emtrion Avari based development kits.
As I asked on v1, why not document the panels together in a single doc?
>
> Signed-off-by: Jan Tuerk <jan.tuerk@emtrion.com>
> ---
> .../bindings/display/panel/edt,etm0700g0bdh6.txt | 9 +++++++++
> drivers/gpu/drm/panel/panel-simple.c | 15 +++++++++++++++
> 2 files changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
^ permalink raw reply
* [PATCH net 1/2] dt-bindings: net: mediatek: add condition to property mediatek,pctl
From: Rob Herring @ 2017-12-21 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e366efc29985d3292c8a1afb1389b5eac57c9037.1513762066.git.sean.wang@mediatek.com>
On Wed, Dec 20, 2017 at 05:47:05PM +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> The property "mediatek,pctl" is only required for SoCs such as MT2701 and
> MT7623, so adding a few words for stating the condition.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> Documentation/devicetree/bindings/net/mediatek-net.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Linus Walleij @ 2017-12-21 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221173235.GK10595@n2100.armlinux.org.uk>
On Thu, Dec 21, 2017 at 6:32 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> What we have here is _really_ a shared interrupt between four
> separate devices, and we need a way to sanely describe resources
> shared between several device instances to pinmux. Unfortunately,
> it seems pinmux is designed around one device having exclusive use
> of a resource, which makes it hard to describe shared interrupts in
> DT.
>
> Given that DT should be a description of the hardware, and should be
> independent of the OS implementation, I'd say this is a pinmux bug,
> because pinmux gets in the way of describing the hardware correctly.
> ;)
Hm that would be annoying. But when I look at it I think it would
actually work. Did you try just assigning the same pin control
state to all the PHY's and see what happens?
Just set
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_mv88e1545>;
on all of them?
I don't think DTC would complain at least.
When I look at the driver subsystem, I don't see anything really
stopping you from doing that and even have three devices selecting
the same "default" pin control state. It seems it will just wind up
three times in pinctrl_select_state() and the first time it calls the pin
control driver to actually set it and the three other times it finds the
state is already correct and returns success.
So the way I read it actually several devices can reference the
same pin control state.
That is, unless there is something I missed. Which I often do...
If it happens to work we should probably put a blurb in the
DT binding that this is expected behaviour though.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] i2c/ARM: davinci: Deep refactoring of I2C recovery
From: Linus Walleij @ 2017-12-21 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2+oa+yzAcpmB+YMuCYMxtFdYknETUtKShZX56G6m76Gg@mail.gmail.com>
On Thu, Dec 21, 2017 at 4:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Dec 20, 2017 at 1:17 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> Alter the DaVinci GPIO recovery fetch to use descriptors
>> all the way down into the board files.
>>
>> Cc: arm at kernel.org
>> Cc: Kevin Hilman <khilman@kernel.org>
>> Cc: Keerthy <j-keerthy@ti.com>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Acked-by: Sekhar Nori <nsekhar@ti.com>
>> Tested-by: Sekhar Nori <nsekhar@ti.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> ChangeLog v1->v2:
>> - Change gpiochip name from gpio_davinci.0 to gpio_davinci, simply.
>
> This seems to clash with "i2c: davinci: Add PM Runtime Support", please
> rebase on top of v4.15-rc and resend.
Strange, where do you see this problem?
I just applied the patch on top of Wolfram's for-next
branch and it worked like a charm. It has the PM Runtime patch
underneath and all.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: realview: remove eb-mp clcd IRQ
From: Linus Walleij @ 2017-12-21 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221213146.3146805-1-arnd@arndb.de>
On Thu, Dec 21, 2017 at 10:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> We get a dtc warning about the CLCD interrupt being invalid:
>
> arch/arm/boot/dts/arm-realview-eb-11mp-ctrevb.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd at 10008000
>
> According to the datasheet I found and the old board file, this
> line is not connected, so I'm removing the respective properties here.
>
> Link: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0411d/index.html
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
There is some confusion here. There is CLCD "Color LCD"
which is just a code name for PrimeCell PL111 and there is the actual
character LCD which is a hardware thin to talk to a character LCD with
some characters on.
> diff --git a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
So this DTS is for the ARM 11 MP core tile which is described in
DUI0318F. It doesn't even list an IRQ for the character LCD.
> &charlcd {
> - interrupt-parent = <&intc>;
> - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
This was probably me thinking to go back and fill in the right
IRQ and forgetting to actually do it. Sorry :(
> + /* CLCD is not connected here */
Call it character LCD instead to avoid confusion please.
> + /delete-property/interrupt-parent;
> + /delete-property/interrupts;
I don't understand this delete-property business (first time
I see it, but the top level
DTSI (arm-realview-eb.dtsi) does not define any interrupt
so can't you just delete this whole &charlcd?
I do think the reference design has a character LCD, and I
do think it has an interrupt, it's just undocumented so
someone with this board would have to test it manually
to figure out which line it is. Whoever uses this design
will get to it if ever.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: dts: tango4: remove bogus interrupt-controller property
From: Arnd Bergmann @ 2017-12-21 21:48 UTC (permalink / raw)
To: linux-arm-kernel
dtc points out that the parent node of the interrupt controllers is not
actually an interrupt controller itself, and lacks an #interrupt-cells
property:
arch/arm/boot/dts/tango4-vantage-1172.dtb: Warning (interrupts_property): Missing #interrupt-cells in interrupt-parent /soc/interrupt-controller at 6e000
This removes the annotation.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/tango4-common.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/tango4-common.dtsi b/arch/arm/boot/dts/tango4-common.dtsi
index 0ec1b0a317b4..ff72a8efb73d 100644
--- a/arch/arm/boot/dts/tango4-common.dtsi
+++ b/arch/arm/boot/dts/tango4-common.dtsi
@@ -156,7 +156,6 @@
reg = <0x6e000 0x400>;
ranges = <0 0x6e000 0x400>;
interrupt-parent = <&gic>;
- interrupt-controller;
#address-cells = <1>;
#size-cells = <1>;
--
2.9.0
^ permalink raw reply related
* [PATCH] ARM: dts: ls1021a: fix incorrect clock references
From: Arnd Bergmann @ 2017-12-21 21:44 UTC (permalink / raw)
To: linux-arm-kernel
dtc warns about two 'clocks' properties that have an extraneous '1'
at the end:
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Property 'clocks', cell 1 is not a phandle reference in /soc/i2c at 2180000/mux at 77/i2c at 4/sgtl5000 at 2a
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller at 1400000 or bad phandle (referred from /soc/i2c at 2180000/mux at 77/i2c at 4/sgtl5000 at 2a:clocks[1])
Property 'clocks', cell 1 is not a phandle reference in /soc/i2c at 2190000/sgtl5000 at a
arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller at 1400000 or bad phandle (referred from /soc/i2c at 2190000/sgtl5000 at a:clocks[1])
The clocks that get referenced here are fixed-rate, so they do not
take any argument, and dtc interprets the next cell as a phandle, which
is invalid.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/ls1021a-qds.dts | 2 +-
arch/arm/boot/dts/ls1021a-twr.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ls1021a-qds.dts b/arch/arm/boot/dts/ls1021a-qds.dts
index 940875316d0f..67b4de0e3439 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -215,7 +215,7 @@
reg = <0x2a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
};
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
index a8b148ad1dd2..44715c8ef756 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -187,7 +187,7 @@
reg = <0x0a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
--
2.9.0
^ permalink raw reply related
* [PATCH] ARM: realview: remove eb-mp clcd IRQ
From: Arnd Bergmann @ 2017-12-21 21:31 UTC (permalink / raw)
To: linux-arm-kernel
We get a dtc warning about the CLCD interrupt being invalid:
arch/arm/boot/dts/arm-realview-eb-11mp-ctrevb.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd at 10008000
According to the datasheet I found and the old board file, this
line is not connected, so I'm removing the respective properties here.
Link: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0411d/index.html
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/arm-realview-eb-mp.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
index 7b8d90b7aeea..e45548ca229a 100644
--- a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
+++ b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
@@ -151,8 +151,9 @@
};
&charlcd {
- interrupt-parent = <&intc>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ /* CLCD is not connected here */
+ /delete-property/interrupt-parent;
+ /delete-property/interrupts;
};
&serial0 {
--
2.9.0
^ permalink raw reply related
* [PATCH] ARM: dts: exynos: fix RTC interrupt for exynos5410
From: Arnd Bergmann @ 2017-12-21 21:30 UTC (permalink / raw)
To: linux-arm-kernel
According to the comment added to exynos_dt_pmu_match[] in commit
8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"),
the RTC is not able to wake up the system through the PMU on Exynos5410,
unlike Exynos5420.
However, when the RTC DT node got added, it was a straight copy of
the Exynos5420 node, which now causes a warning from dtc.
This removes the incorrect interrupt-parent, which should get the
interrupt working and avoid the warning.
Fixes: e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/exynos5410.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
index 06713ec86f0d..d2174727df9a 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -333,7 +333,6 @@
&rtc {
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
- interrupt-parent = <&pmu_system_controller>;
status = "disabled";
};
--
2.9.0
^ permalink raw reply related
* linux-next: manual merge of the aspeed tree with the arm-soc tree
From: Stephen Rothwell @ 2017-12-21 21:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi Joel,
Today's linux-next merge of the aspeed tree got conflicts in:
arch/arm/boot/dts/Makefile
arch/arm/boot/dts/aspeed-g4.dtsi
between commits:
d2271826e58b ("ARM: dts: aspeed-g4: Correct VUART IRQ number")
ea04d6b456b2 ("ARM: make ARCH_S3C24XX select USE_OF and clean-up boot/dts/Makefile")
from the arm-soc tree and commits:
bb8155ada490 ("ARM: dts: aspeed: Add proper clock references")
8b42ae23ee0a ("ARM: dts: aspeed: Sort ASPEED entries in makefile")
2e3de60a1034 ("ARM: dts: aspeed: Add Witherspoon BMC machine")
46d83989fde3 ("ARM: dts: aspeed: Add Ingrasys Zaius BMC machine")
f88bc8e15f1c ("ARM: dts: aspeed: Add Qanta Q71L BMC machine")
from the aspeed tree.
I fixed it up (see below (the dtsi file has a common patch part between
d2271826e58b and bb8155ada490) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your
tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/boot/dts/Makefile
index 032138d9c60b,5ab5d9169511..000000000000
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@@ -1102,6 -1101,11 +1102,10 @@@ dtb-$(CONFIG_ARCH_MEDIATEK) +=
mt8127-moose.dtb \
mt8135-evbp1.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
- dtb-$(CONFIG_ARCH_ASPEED) += aspeed-bmc-opp-palmetto.dtb \
+ dtb-$(CONFIG_ARCH_ASPEED) += \
+ aspeed-ast2500-evb.dtb \
+ aspeed-bmc-opp-palmetto.dtb \
aspeed-bmc-opp-romulus.dtb \
- aspeed-ast2500-evb.dtb
+ aspeed-bmc-opp-witherspoon.dtb \
+ aspeed-bmc-opp-zaius.dtb \
+ aspeed-bmc-quanta-q71l.dtb
-endif
^ permalink raw reply
* [GIT PULL 1/3] ARM: dts: exynos: DTS for v4.16
From: Arnd Bergmann @ 2017-12-21 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220173643.5840-3-krzk@kernel.org>
On Wed, Dec 20, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Krzysztof Kozlowski (2):
> ARM: dts: exynos: Add missing interrupt-controller properties to Exynos5410 PMU
I just looked through the remaining warnings in 4.15 and noticed that
you had sent this
only for 4.16, not as a bug fix.
Looking closer, it seems incorrect:
According to the comment added to exynos_dt_pmu_match[] in commit
8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"),
the RTC is not able to wake up the system through the PMU on Exynos5410,
unlike Exynos5420. However, when the RTC DT node got added in commit
e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410"), it was
a straight copy of the Exynos5420 node, which now causes the warning from dtc,
and now you add the "interrupt-controller" property to the device node, but
the code still doesn't handle it at all.
Can you have another look here?
Arnd
^ permalink raw reply
* [PATCH V2 3/9] ARM: stm32: prepare stm32 family to welcome armv7 architecture
From: Arnd Bergmann @ 2017-12-21 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4093a02c-3216-d668-a6d8-1ce76046b554@st.com>
On Thu, Dec 21, 2017 at 5:39 PM, Ludovic BARRE <ludovic.barre@st.com> wrote:
>>>
>> Currently "restart" is not functional on stm32 MCU (at least for
>> stm32f746, I will check on others MCU). My fear is if Ludovic made some
>> patches to make "armv7m_restart" the default ".restart" function for all
>> armv7-m platform, he will not be able to test it on stm32 MCU (as it is not
>> currently working). I propose to do it in 2 steps:
>>
>> 1-Keep as you suggest only one board-dt.c file for both (MCU and MPU) and
>> remove ".restart" function.
>>
>> 2-Investigate and send patches around ".restart" for both in an other
>> series.
>
>
> I resend
Yes, that seems fine.
Arnd
^ permalink raw reply
* [GIT PULL 2/2] Rockchip dts64 changes for 4.16
From: Arnd Bergmann @ 2017-12-21 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2062410.Qz0JYku65n@phil>
On Thu, Dec 21, 2017 at 7:31 PM, Heiko Stuebner <heiko@sntech.de> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.16-rockchip-dts64-1
>
> for you to fetch changes up to 13bc2c0a6a14f430abaa6a859792418644b7febd:
>
> arm64: dts: rockchip: Add efuse device node for RK3328 SoC (2017-12-20 13:12:13 +0100)
>
> ----------------------------------------------------------------
> General RK3399 gets Mipi nodes, fixes for usb3 support and better support
> for the type-c phys. The Kevin Chromebooks based on rk3399 now can use their
> internal edp displays. RK3328 gets its efuse node and Mali450 gpu node,
> which actually produces already some nice results with the WIP Lima driver.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 1/2] Rockchip dts32 changes for 4.16
From: Arnd Bergmann @ 2017-12-21 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2013174.TmhWXT9G0E@phil>
On Thu, Dec 21, 2017 at 7:30 PM, Heiko Stuebner <heiko@sntech.de> wrote:
> Hi Arnd, Kevin, Olof,
>
> please find below and in the next mail Rockchip changes for 4.16.
> The volume especially on 32bit is quite low this time, possibly due
> to the holiday season. So if nothing looks bad, please pull
>
> Thanks and merry xmas
> Heiko
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.16-rockchip-dts32-1
>
> for you to fetch changes up to fe8fd85a23a746bd7f0a14e5dcd55c9bc517a055:
>
> ARM: dts: rockchip: add reset property for rk3066a-rayeager emac phy (2017-12-16 21:09:37 +0100)
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH 1/2] clk: rename clk_core_get_boundaries() to clk_hw_get_boundaries() and expose
From: Stephen Boyd @ 2017-12-21 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513872282-5370-2-git-send-email-al.kochet@gmail.com>
On 12/21, Alexander Kochetkov wrote:
> In order to provide a way to know clock limits to clock providers.
>
> The patch is needed for fixing commit 5d890c2df900 ("clk: rockchip:
> add special approximation to fix up fractional clk's jitter").
> Custom approximation function introduced by the patch, can
> select frequency rate larger than one configured using
> clk_set_max_rate().
>
> Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
> ---
Can you convert to the determine_rate op instead of round_rate?
That function should tell you the min/max limits so that you
don't need to query that information from the core.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [GIT PULL 2/3] arm64: dts: exynos: DTS for v4.16
From: Arnd Bergmann @ 2017-12-21 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPfKXWAmWUb86YW3zP3iniCU_hnZuacW4HONvYbmi0uoag@mail.gmail.com>
On Thu, Dec 21, 2017 at 8:31 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, Dec 21, 2017 at 5:50 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Dec 20, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> The Nexell series are similar to Exynos but this is different company
> so probably they would end up in different sub-arch. Only some IP
> blocks are similar to Exynos even though the datasheet has Samsung
> marks. I saw patches for U-Boot (I do not remember the author) so
> maybe soon something will happen on LKML.
Ok. When I looked at an old 32-bit 3.4 kernel tree, I could see no similarity
to Exynos, but it seems that there is now an active development tree for
a 64-bit 4.x kernel for the Samsung Artik board series, just no patches.
Arnd
^ permalink raw reply
* [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc
From: Linus Walleij @ 2017-12-21 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1MF-ezKyHhzqW0eGDa_2sCEyGZ62Qcxh2itpwHiLHxaA@mail.gmail.com>
On Thu, Dec 21, 2017 at 6:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Dec 21, 2017 at 5:57 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Wed, Dec 20, 2017 at 2:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>>> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
>>> meaning that this is expected to be removed at some point in the future,
>>> with gcc-8.0 as the earliest.
>>>
>>> When building the kernel, the difference between ARMv4 and ARMv4T
>>> is relatively small because the kernel never runs THUMB instructions
>>> on ARMv4T and does not need any support for interworking.
>>>
>>> For any future compiler that does not support -march=armv4, we now
>>> fall back to -march=armv4t as the architecture level selection,
>>> but keep using -march=armv4 by default as long as that is supported
>>> by the compiler.
>>>
>>> Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
>>> will go away at the same time as -march=armv4, so this adds a check
>>> to see if the compiler supports them, falling back to no -mtune
>>> option otherwise.
>>>
>>> Compiling with -march=armv4t leads the compiler to using 'bx reg'
>>> instructions instead of 'mov pc,reg'. This is not supported on
>>> ARMv4 based CPUs, but the linker can work around this by rewriting
>>> those instructions to the ARMv4 version if we pass --fix-v4bx
>>> to the linker. This should work with binutils-2.15 (released
>>> May 2004) or higher, and we can probably assume that anyone using
>>> gcc-7.x will have a much more recent binutils version as well.
>>>
>>> However, in order to still allow users of old toolchains to link
>>> the kernel, we only pass the option to linkers that support it,
>>> based on a $(ld-option ...) call. I'm intentionally passing the
>>> flag to all linker versions here regardless of whether it's needed
>>> or not, so we can more easily spot any regressions if something
>>> goes wrong.
>>>
>>> For consistency, I'm passing the --fix-v4bx flag for both the
>>> vmlinux final link and the individual loadable modules.
>>> The module loader code already interprets the R_ARM_V4BX relocations
>>> in loadable modules and converts bx instructions into mov even
>>> when running on ARMv4T or ARMv5 processors. This is now redundant
>>> when we pass --fix-v4bx to the linker for building modules, but
>>> I see no harm in leaving the current implementation and doing both.
>>>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> ---
>>> Please test by making the -march=armv4t switch unconditional
>>> and see if that results in a working kernel
>>
>> I did this:
>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
>> index 66e46aec0cd0..3944ecd6cd31 100644
>> --- a/arch/arm/Makefile
>> +++ b/arch/arm/Makefile
>> @@ -81,7 +81,7 @@ arch-$(CONFIG_CPU_32v6K)
>> =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,
>> endif
>> arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 $(call
>> cc-option,-march=armv5te,-march=armv4t)
>> arch-$(CONFIG_CPU_32v4T) =-D__LINUX_ARM_ARCH__=4 -march=armv4t
>> -arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 $(call
>> cc-option,-march=armv4,-march=armv4t)
>> +arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 -march=armv4t
>> arch-$(CONFIG_CPU_32v3) =-D__LINUX_ARM_ARCH__=3 -march=armv3
>>
>> Built and booted on the Gemini platform.
>>
>> It crashes immediately and goes into the boot loader
>> on thos FA-526 based platform.
>
> Hmm, maybe the decompressor needs the fixup separately. Can you try
> something like this completely untested patch on top?
>
> Arnd
>
> diff --git a/arch/arm/boot/compressed/Makefile
> b/arch/arm/boot/compressed/Makefile
> index f0548b6948f1..0e141b2cae98 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -134,6 +134,11 @@ endif
> ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
> LDFLAGS_vmlinux += --be8
> endif
> +
> +ifdef CONFIG_CPU_32v4
> +LDFLAGS_vmlinux += --fix-v4bx
> +endif
> +
Yes this work! The kernel and userspace comes up.
With this folded in:
Tested-by: Linus Walleij <linus.walleij@linaro.org> for FA526
I will try to test it on SA110 (NetWinder) tomorrow.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] ARM: probes: avoid adding kprobes to sensitive kernel-entry/exit code
From: Sam Protsenko @ 2017-12-21 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1eIYic-0007t7-Df@rmk-PC.armlinux.org.uk>
On 25 November 2017 at 13:33, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> Avoid adding kprobes to any of the kernel entry/exit or startup
> assembly code, or code in the identity-mapped region. This code does
> not conform to the standard C conventions, which means that the
> expectations of the kprobes code is not forfilled.
>
> Placing kprobes at some of these locations results in the kernel trying
> to return to userspace addresses while retaining the CPU in kernel mode.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> arch/arm/include/asm/exception.h | 3 +--
> arch/arm/include/asm/sections.h | 21 +++++++++++++++++++++
> arch/arm/include/asm/traps.h | 12 ------------
> arch/arm/kernel/entry-armv.S | 6 +-----
> arch/arm/kernel/entry-common.S | 1 +
> arch/arm/kernel/stacktrace.c | 14 ++------------
> arch/arm/kernel/traps.c | 4 ++--
> arch/arm/kernel/vmlinux.lds.S | 6 +++---
> arch/arm/mm/fault.c | 5 ++---
> arch/arm/probes/kprobes/core.c | 14 +++++++++++---
> 10 files changed, 44 insertions(+), 42 deletions(-)
>
> diff --git a/arch/arm/include/asm/exception.h b/arch/arm/include/asm/exception.h
> index a7273ad9587a..58e039a851af 100644
> --- a/arch/arm/include/asm/exception.h
> +++ b/arch/arm/include/asm/exception.h
> @@ -10,11 +10,10 @@
>
> #include <linux/interrupt.h>
>
> -#define __exception __attribute__((section(".exception.text")))
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> #define __exception_irq_entry __irq_entry
> #else
> -#define __exception_irq_entry __exception
> +#define __exception_irq_entry
> #endif
>
> #endif /* __ASM_ARM_EXCEPTION_H */
> diff --git a/arch/arm/include/asm/sections.h b/arch/arm/include/asm/sections.h
> index 63dfe1f10335..4ceb4f757d4d 100644
> --- a/arch/arm/include/asm/sections.h
> +++ b/arch/arm/include/asm/sections.h
> @@ -6,4 +6,25 @@
>
> extern char _exiprom[];
>
> +extern char __idmap_text_start[];
> +extern char __idmap_text_end[];
> +extern char __entry_text_start[];
> +extern char __entry_text_end[];
> +extern char __hyp_idmap_text_start[];
> +extern char __hyp_idmap_text_end[];
> +
> +static inline bool in_entry_text(unsigned long addr)
> +{
> + return memory_contains(__entry_text_start, __entry_text_end,
> + (void *)addr, 1);
> +}
> +
> +static inline bool in_idmap_text(unsigned long addr)
> +{
> + void *a = (void *)addr;
> + return memory_contains(__idmap_text_start, __idmap_text_end, a, 1) ||
> + memory_contains(__hyp_idmap_text_start, __hyp_idmap_text_end,
> + a, 1);
> +}
> +
> #endif /* _ASM_ARM_SECTIONS_H */
> diff --git a/arch/arm/include/asm/traps.h b/arch/arm/include/asm/traps.h
> index f9a6c5fc3fd1..a00288d75ee6 100644
> --- a/arch/arm/include/asm/traps.h
> +++ b/arch/arm/include/asm/traps.h
> @@ -28,18 +28,6 @@ static inline int __in_irqentry_text(unsigned long ptr)
> ptr < (unsigned long)&__irqentry_text_end;
> }
>
> -static inline int in_exception_text(unsigned long ptr)
> -{
> - extern char __exception_text_start[];
> - extern char __exception_text_end[];
> - int in;
> -
> - in = ptr >= (unsigned long)&__exception_text_start &&
> - ptr < (unsigned long)&__exception_text_end;
> -
> - return in ? : __in_irqentry_text(ptr);
> -}
> -
> extern void __init early_trap_init(void *);
> extern void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long frame);
> extern void ptrace_break(struct task_struct *tsk, struct pt_regs *regs);
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index 10ad44f3886a..b8ab97dfdd17 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -82,11 +82,7 @@
> #endif
> .endm
>
> -#ifdef CONFIG_KPROBES
> - .section .kprobes.text,"ax",%progbits
> -#else
> - .text
> -#endif
> + .section .entry.text,"ax",%progbits
>
> /*
> * Invalid mode handlers
> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
> index e655dcd0a933..3c4f88701f22 100644
> --- a/arch/arm/kernel/entry-common.S
> +++ b/arch/arm/kernel/entry-common.S
> @@ -37,6 +37,7 @@ saved_pc .req lr
> #define TRACE(x...)
> #endif
>
> + .section .entry.text,"ax",%progbits
> .align 5
> #if !(IS_ENABLED(CONFIG_TRACE_IRQFLAGS) || IS_ENABLED(CONFIG_CONTEXT_TRACKING))
> /*
> diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
> index 65228bf4c6df..a56e7c856ab5 100644
> --- a/arch/arm/kernel/stacktrace.c
> +++ b/arch/arm/kernel/stacktrace.c
> @@ -3,6 +3,7 @@
> #include <linux/sched/debug.h>
> #include <linux/stacktrace.h>
>
> +#include <asm/sections.h>
> #include <asm/stacktrace.h>
> #include <asm/traps.h>
>
> @@ -63,7 +64,6 @@ EXPORT_SYMBOL(walk_stackframe);
> #ifdef CONFIG_STACKTRACE
> struct stack_trace_data {
> struct stack_trace *trace;
> - unsigned long last_pc;
> unsigned int no_sched_functions;
> unsigned int skip;
> };
> @@ -87,16 +87,7 @@ static int save_trace(struct stackframe *frame, void *d)
> if (trace->nr_entries >= trace->max_entries)
> return 1;
>
> - /*
> - * in_exception_text() is designed to test if the PC is one of
> - * the functions which has an exception stack above it, but
> - * unfortunately what is in frame->pc is the return LR value,
> - * not the saved PC value. So, we need to track the previous
> - * frame PC value when doing this.
> - */
> - addr = data->last_pc;
> - data->last_pc = frame->pc;
> - if (!in_exception_text(addr))
> + if (!in_entry_text(frame->pc))
> return 0;
>
> regs = (struct pt_regs *)frame->sp;
> @@ -114,7 +105,6 @@ static noinline void __save_stack_trace(struct task_struct *tsk,
> struct stackframe frame;
>
> data.trace = trace;
> - data.last_pc = ULONG_MAX;
> data.skip = trace->skip;
> data.no_sched_functions = nosched;
>
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 5de2bc46153f..95978073db53 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -73,7 +73,7 @@ void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long
> printk("Function entered at [<%08lx>] from [<%08lx>]\n", where, from);
> #endif
>
> - if (in_exception_text(where))
> + if (in_entry_text(from))
> dump_mem("", "Exception stack", frame + 4, frame + 4 + sizeof(struct pt_regs));
> }
>
> @@ -434,7 +434,7 @@ static int call_undef_hook(struct pt_regs *regs, unsigned int instr)
> return fn ? fn(regs, instr) : 1;
> }
>
> -asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
> +asmlinkage void do_undefinstr(struct pt_regs *regs)
> {
> unsigned int instr;
> siginfo_t info;
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index ee53f6518872..84a1ae3ce46e 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -105,9 +105,9 @@ SECTIONS
> .text : { /* Real text segment */
> _stext = .; /* Text and read-only data */
> IDMAP_TEXT
> - __exception_text_start = .;
> - *(.exception.text)
> - __exception_text_end = .;
> + __entry_text_start = .;
> + *(.entry.text)
> + __entry_text_end = .;
> IRQENTRY_TEXT
> SOFTIRQENTRY_TEXT
> TEXT_TEXT
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index 42f585379e19..b75eada23d0a 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -21,7 +21,6 @@
> #include <linux/highmem.h>
> #include <linux/perf_event.h>
>
> -#include <asm/exception.h>
> #include <asm/pgtable.h>
> #include <asm/system_misc.h>
> #include <asm/system_info.h>
> @@ -545,7 +544,7 @@ hook_fault_code(int nr, int (*fn)(unsigned long, unsigned int, struct pt_regs *)
> /*
> * Dispatch a data abort to the relevant handler.
> */
> -asmlinkage void __exception
> +asmlinkage void
> do_DataAbort(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
> {
> const struct fsr_info *inf = fsr_info + fsr_fs(fsr);
> @@ -578,7 +577,7 @@ hook_ifault_code(int nr, int (*fn)(unsigned long, unsigned int, struct pt_regs *
> ifsr_info[nr].name = name;
> }
>
> -asmlinkage void __exception
> +asmlinkage void
> do_PrefetchAbort(unsigned long addr, unsigned int ifsr, struct pt_regs *regs)
> {
> const struct fsr_info *inf = ifsr_info + fsr_fs(ifsr);
> diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
> index 52d1cd14fda4..e90cc8a08186 100644
> --- a/arch/arm/probes/kprobes/core.c
> +++ b/arch/arm/probes/kprobes/core.c
> @@ -32,6 +32,7 @@
> #include <linux/percpu.h>
> #include <linux/bug.h>
> #include <asm/patch.h>
> +#include <asm/sections.h>
>
> #include "../decode-arm.h"
> #include "../decode-thumb.h"
> @@ -64,9 +65,6 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
> int is;
> const struct decode_checker **checkers;
>
> - if (in_exception_text(addr))
> - return -EINVAL;
> -
> #ifdef CONFIG_THUMB2_KERNEL
> thumb = true;
> addr &= ~1; /* Bit 0 would normally be set to indicate Thumb code */
> @@ -680,3 +678,13 @@ int __init arch_init_kprobes()
> #endif
> return 0;
> }
> +
> +bool arch_within_kprobe_blacklist(unsigned long addr)
> +{
> + void *a = (void *)addr;
> +
> + return __in_irqentry_text(addr) ||
> + in_entry_text(addr) ||
> + in_idmap_text(addr) ||
> + memory_contains(__kprobes_text_start, __kprobes_text_end, a, 1);
> +}
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Russel,
Can you please tell us what is the status of this patch? It fixes the
issue for us ([1]), but we are waiting for it to be merged.
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Thanks!
[1] https://bugs.linaro.org/show_bug.cgi?id=3297
^ 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