* [PATCH] media: rcar-vin: Drop unnecessary register properties from example vin port
From: Niklas Söderlund @ 2018-05-13 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509184558.14960-1-horms+renesas@verge.net.au>
Hi Simon,
Thanks for your patch.
On 2018-05-09 20:45:58 +0200, Simon Horman wrote:
> The example vin port node does not have an address and thus does not
> need address-cells or address size-properties.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1c669..2a0c59e97f40 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -107,9 +107,6 @@ Board setup example for Gen2 platforms (vin1 composite video input)
> status = "okay";
>
> port {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> vin1ep0: endpoint {
> remote-endpoint = <&adv7180>;
> bus-width = <8>;
> --
> 2.11.0
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Niklas Söderlund @ 2018-05-13 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526032802-14376-4-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your patch.
On 2018-05-11 12:00:02 +0200, Jacopo Mondi wrote:
> Describe HDMI input connected to VIN4 interface for R-Car D3 Draak
> development board.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 68 ++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> index d03f194..e0ce462 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -59,6 +59,17 @@
> };
> };
>
> + hdmi-in {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&adv7612_in>;
> + };
> + };
> + };
> +
> memory at 48000000 {
> device_type = "memory";
> /* first 128MB is reserved for secure area. */
> @@ -142,6 +153,11 @@
> groups = "usb0";
> function = "usb0";
> };
> +
> + vin4_pins: vin4 {
> + groups = "vin4_data24", "vin4_sync", "vin4_clk", "vin4_clkenb";
> + function = "vin4";
> + };
> };
>
> &i2c0 {
> @@ -154,6 +170,35 @@
> reg = <0x50>;
> pagesize = <8>;
> };
> +
> + hdmi-decoder at 4c {
> + compatible = "adi,adv7612";
> + reg = <0x4c>;
> + default-input = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + adv7612_in: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> + };
> +
> + port at 2 {
> + reg = <2>;
> + adv7612_out: endpoint {
> + pclk-sample = <0>;
> + hsync-active = <0>;
> + vsync-active = <0>;
This differs from the Gen2 DT bindings which is a very similar hardware
setup using the same components. Defining these properties will make the
bus marked as V4L2_MBUS_PARALLEL instead of V4L2_MBUS_BT656.
This will change how the hardware is configured for capture if the media
bus is in a UYVY format, see VNMC_INF register in rvin_setup(). Maybe
this it not an issue here but still I'm curious to why this differ
between Gen2 and Gen3 :-)
> +
> + remote-endpoint = <&vin4_in>;
> + };
> + };
> + };
> + };
> };
>
> &i2c1 {
> @@ -246,3 +291,26 @@
> timeout-sec = <60>;
> status = "okay";
> };
> +
> +&vin4 {
> + pinctrl-0 = <&vin4_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> +
> + vin4_in: endpoint {
> + hsync-active = <0>;
> + vsync-active = <0>;
Comparing this to the Gen2 bindings some properties are missing,
bus-width = <24>;
pclk-sample = <1>;
data-active = <1>;
This is not a big deal as the VIN driver don't use these properties so
no functional change should come of this but still a difference.
Over all I'm happy with this change but before I add my tag I would like
to understand why it differs from the Gen2 configuration for the adv7612
properties.
Also on a side not it is possible with hardware switches on the board
switch the VIN4 source to a completely different pipeline CVBS connector
-> adv7180 -> VIN4. But I think it's best we keep the HDMI as default as
this seems to be how the boards are shipped. But maybe mentioning this
in the commit message would not hurt if you end-up resending the patch.
> +
> + remote-endpoint = <&adv7612_out>;
> + };
> + };
> + };
> +};
> --
> 2.7.4
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Use dedicated DT bindings for Odroid X/X2, U3
From: Krzysztof Kozlowski @ 2018-05-13 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511080947.3057-1-s.nawrocki@samsung.com>
On Fri, May 11, 2018 at 10:09:47AM +0200, Sylwester Nawrocki wrote:
> Use dedicated Odroid audio subsystem DT bindings instead of the simple-card.
> This adds support for audio on the HDMI interface.
How about changing the subject to "Add suppor for audio over HDMI for
Odroid X/X2/U3"?
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 33 ++++++++++++++-----------
> arch/arm/boot/dts/exynos4412-odroidu3.dts | 7 +++---
> arch/arm/boot/dts/exynos4412-odroidx.dts | 7 +++---
> 3 files changed, 27 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index d7ad07fd48f9..bad08e70358a 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -37,20 +37,12 @@
> };
>
> sound: sound {
> - compatible = "simple-audio-card";
> -
> - simple-audio-card,format = "i2s";
> - simple-audio-card,bitclock-master = <&link0_codec>;
> - simple-audio-card,frame-master = <&link0_codec>;
> -
> - simple-audio-card,cpu {
> + cpu {
> sound-dai = <&i2s0 0>;
> - system-clock-frequency = <19200000>;
> };
>
> - link0_codec: simple-audio-card,codec {
> - sound-dai = <&max98090>;
> - clocks = <&i2s0 CLK_I2S_CDCLK>;
> + codec {
> + sound-dai = <&hdmi>, <&max98090>;
> };
> };
>
> @@ -142,14 +134,25 @@
> pinctrl-0 = <>;
> };
>
> +&clock {
> + assigned-clocks = <&clock CLK_FOUT_EPLL>;
> + assigned-clock-rates = <45158401>;
> +};
> +
> &clock_audss {
> assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
> <&clock_audss EXYNOS_MOUT_I2S>,
> <&clock_audss EXYNOS_DOUT_SRP>,
> - <&clock_audss EXYNOS_DOUT_AUD_BUS>;
> + <&clock_audss EXYNOS_DOUT_AUD_BUS>,
> + <&clock_audss EXYNOS_DOUT_I2S>;
> +
> assigned-clock-parents = <&clock CLK_FOUT_EPLL>,
> - <&clock_audss EXYNOS_MOUT_AUDSS>;
> - assigned-clock-rates = <0>, <0>, <192000000>, <19200000>;
> + <&clock_audss EXYNOS_MOUT_AUDSS>;
> +
> + assigned-clock-rates = <0>, <0>,
> + <196608001>,
> + <(196608001 / 2)>,
> + <(196608001 / 8)>;
> };
>
> &cpu0 {
> @@ -498,6 +501,8 @@
> pinctrl-0 = <&i2s0_bus>;
> pinctrl-names = "default";
> status = "okay";
> + assigned-clocks = <&i2s0 CLK_I2S_RCLK_SRC>;
> + assigned-clock-parents = <&clock_audss EXYNOS_SCLK_I2S>;
> };
>
> &mixer {
> diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> index bdcd4523cc1c..7a94a423097d 100644
> --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> @@ -113,11 +113,12 @@
> };
>
> &sound {
> - simple-audio-card,name = "Odroid-U3";
> - simple-audio-card,widgets =
> + compatible = "hardkernel,odroid-xu4-audio";
The compatible is the same for all users using DTSI so it could be moved
to the exynos4412-odroid-common.dtsi itself.
Best regards,
Krzysztof
> + model = "Odroid-U3";
> + samsung,audio-widgets =
> "Headphone", "Headphone Jack",
> "Speakers", "Speakers";
> - simple-audio-card,routing =
> + samsung,audio-routing =
> "Headphone Jack", "HPL",
> "Headphone Jack", "HPR",
> "Headphone Jack", "MICBIAS",
> diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts b/arch/arm/boot/dts/exynos4412-odroidx.dts
> index 2dff129bc2ad..f0d5037f3a5d 100644
> --- a/arch/arm/boot/dts/exynos4412-odroidx.dts
> +++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
> @@ -97,12 +97,13 @@
> };
>
> &sound {
> - simple-audio-card,name = "Odroid-X";
> - simple-audio-card,widgets =
> + compatible = "hardkernel,odroid-xu4-audio";
> + model = "Odroid-X";
> + samsung,audio-widgets =
> "Headphone", "Headphone Jack",
> "Microphone", "Mic Jack",
> "Microphone", "DMIC";
> - simple-audio-card,routing =
> + samsung,audio-routing =
> "Headphone Jack", "HPL",
> "Headphone Jack", "HPR",
> "IN1", "Mic Jack",
> --
> 2.14.2
>
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Niklas Söderlund @ 2018-05-13 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513081750.xcpc5ya3yl7ezkjd@verge.net.au>
Hi Simon,
On 2018-05-13 10:17:50 +0200, Simon Horman wrote:
> On Fri, May 11, 2018 at 12:00:02PM +0200, Jacopo Mondi wrote:
> > Describe HDMI input connected to VIN4 interface for R-Car D3 Draak
> > development board.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> Hi Niklas,
>
> As you reviewed the rest of the series I'm wondering if you're planning
> to review this patch too.
Yes, I did not have schematics for D3 on hand when reviewing the rest of
the series. Will review it now that I do, thanks for the ping :-)
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH] clk: stm32mp1: Fix a memory leak in 'clk_stm32_register_gate_ops()'
From: Christophe JAILLET @ 2018-05-13 11:17 UTC (permalink / raw)
To: linux-arm-kernel
We allocate some memory which is neither used, nor referenced by anything.
So axe it.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This patch as not been compile-tested, I don't have the corresponding arch
and have not taken time to cross-compile it.
---
drivers/clk/clk-stm32mp1.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index edd3cf451401..dfb9cb5bd0c4 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -579,14 +579,9 @@ clk_stm32_register_gate_ops(struct device *dev,
spinlock_t *lock)
{
struct clk_init_data init = { NULL };
- struct clk_gate *gate;
struct clk_hw *hw;
int ret;
- gate = kzalloc(sizeof(*gate), GFP_KERNEL);
- if (!gate)
- return ERR_PTR(-ENOMEM);
-
init.name = name;
init.parent_names = &parent_name;
init.num_parents = 1;
@@ -604,10 +599,8 @@ clk_stm32_register_gate_ops(struct device *dev,
hw->init = &init;
ret = clk_hw_register(dev, hw);
- if (ret) {
- kfree(gate);
+ if (ret)
hw = ERR_PTR(ret);
- }
return hw;
}
--
2.17.0
^ permalink raw reply related
* [PATCH] arm64: dts: renesas: r8a77990: Add GPIO device nodes
From: Sergei Shtylyov @ 2018-05-13 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513090855.25982-1-horms+renesas@verge.net.au>
Hello!
On 5/13/2018 12:08 PM, Simon Horman wrote:
> The compat string renesas,gpio-rcar has been deprecated since v4.14,
> the same release that r8a77990 SoC support was added. Thus
> renesas,gpio-rcar can safely be removed without any risk of behaviour
> changes between old and new mainline kernels and DTBs.
This hardly matches the subject. :-)
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77990: Add GPIO device nodes
From: Simon Horman @ 2018-05-13 9:08 UTC (permalink / raw)
To: linux-arm-kernel
The compat string renesas,gpio-rcar has been deprecated since v4.14,
the same release that r8a77990 SoC support was added. Thus
renesas,gpio-rcar can safely be removed without any risk of behaviour
changes between old and new mainline kernels and DTBs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 21 +++++++--------------
1 file changed, 7 insertions(+), 14 deletions(-)
Based on renesas-devel-20180511-v4.17-rc4
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 2506f46293e8..f3426266b5ea 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -88,8 +88,7 @@
gpio0: gpio at e6050000 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6050000 0 0x50>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
@@ -104,8 +103,7 @@
gpio1: gpio at e6051000 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6051000 0 0x50>;
interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
@@ -120,8 +118,7 @@
gpio2: gpio at e6052000 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6052000 0 0x50>;
interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
@@ -136,8 +133,7 @@
gpio3: gpio at e6053000 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6053000 0 0x50>;
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
@@ -152,8 +148,7 @@
gpio4: gpio at e6054000 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6054000 0 0x50>;
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
@@ -168,8 +163,7 @@
gpio5: gpio at e6055000 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6055000 0 0x50>;
interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
@@ -184,8 +178,7 @@
gpio6: gpio at e6055400 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6055400 0 0x50>;
interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
--
2.11.0
^ permalink raw reply related
* [PATCH V3 0/3] cpufreq: dt: Allow platforms to provide suspend/resume hooks
From: Rafael J. Wysocki @ 2018-05-13 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1524561482.git.viresh.kumar@linaro.org>
On Tuesday, April 24, 2018 11:39:44 AM CEST Viresh Kumar wrote:
> Hi Rafael,
>
> These patches are already tested by Miquel and are ready to get merged.
> Please pick them as part of 4.18 stuff whenever you do that.
>
> I have updated the cpufreq-dt driver to allow platform specific
> suspend/resume hooks and done some minor cleanup in the driver. I have
> updated Miquel's patch and applied that on top of all this.
>
> Thanks.
>
> V2->V3:
> - Don't double put the clock.
> - Fix commit log of 3/3.
> - Add tested-by from Miquel.
> - There was no V2 of 1-2/3 but only 3/3 on the lists. All are marked as
> V3 to clear things out.
>
> --
> viresh
>
> [1] https://lkml.kernel.org/r/20180421141943.25705-1-miquel.raynal at bootlin.com
>
> Miquel Raynal (1):
> cpufreq: add suspend/resume support in Armada 37xx DVFS driver
>
> Viresh Kumar (2):
> cpufreq: dt: Allow platform specific suspend/resume callbacks
> cpufreq: armada: Free resources on error paths
>
> drivers/cpufreq/armada-37xx-cpufreq.c | 100 +++++++++++++++++++++++++++++-----
> drivers/cpufreq/cpufreq-dt.c | 10 +++-
> drivers/cpufreq/cpufreq-dt.h | 5 ++
> 3 files changed, 100 insertions(+), 15 deletions(-)
>
>
Applied including the v4 of patch [3/3], thanks!
^ permalink raw reply
* [PATCH] cpufreq: s3c2440: fix spelling mistake: "divsiors" -> "divisors"
From: Rafael J. Wysocki @ 2018-05-13 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502053721.5h6jhicjsjss2ixe@vireshk-i7>
On Wednesday, May 2, 2018 7:37:21 AM CEST Viresh Kumar wrote:
> On 30-04-18, 15:48, Colin King wrote:
> > From: Colin Ian King <colin.king@canonical.com>
> >
> > Trivial fix to spelling mistake in s3c_freq_dbg debug message text.
> >
> > Signed-off-by: Colin Ian King <colin.king@canonical.com>
> > ---
> > drivers/cpufreq/s3c2440-cpufreq.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/s3c2440-cpufreq.c b/drivers/cpufreq/s3c2440-cpufreq.c
> > index d0d75b65ddd6..d2f67b7a20dd 100644
> > --- a/drivers/cpufreq/s3c2440-cpufreq.c
> > +++ b/drivers/cpufreq/s3c2440-cpufreq.c
> > @@ -143,7 +143,7 @@ static void s3c2440_cpufreq_setdivs(struct s3c_cpufreq_config *cfg)
> > {
> > unsigned long clkdiv, camdiv;
> >
> > - s3c_freq_dbg("%s: divsiors: h=%d, p=%d\n", __func__,
> > + s3c_freq_dbg("%s: divisors: h=%d, p=%d\n", __func__,
> > cfg->divs.h_divisor, cfg->divs.p_divisor);
> >
> > clkdiv = __raw_readl(S3C2410_CLKDIVN);
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
>
Applied, thanks!
^ permalink raw reply
* [PATCH 2/2] arm64: Clear the stack
From: Alexander Popov @ 2018-05-13 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511161317.57k6prl54xjmsit3@lakrids.cambridge.arm.com>
Hello Mark,
Thanks a lot for your reply!
On 11.05.2018 19:13, Mark Rutland wrote:
> On Fri, May 11, 2018 at 06:50:09PM +0300, Alexander Popov wrote:
>> On 06.05.2018 11:22, Alexander Popov wrote:
>>> On 04.05.2018 14:09, Mark Rutland wrote:
>>>>>>> + stack_left = sp & (THREAD_SIZE - 1);
>>>>>>> + BUG_ON(stack_left < 256 || size >= stack_left - 256);
>>>>>>
>>>>>> Is this arbitrary, or is there something special about 256?
>>>>>>
>>>>>> Even if this is arbitrary, can we give it some mnemonic?
>>>>>
>>>>> It's just a reasonable number. We can introduce a macro for it.
>>>>
>>>> I'm just not sure I see the point in the offset, given things like
>>>> VMAP_STACK exist. BUG_ON() handling will likely require *more* than 256
>>>> bytes of stack, so it seems superfluous, as we'd be relying on stack
>>>> overflow detection at that point.
>>>>
>>>> I can see that we should take the CONFIG_SCHED_STACK_END_CHECK offset
>>>> into account, though.
>>>
>>> Mark, thank you for such an important remark!
>>>
>>> In Kconfig STACKLEAK implies but doesn't depend on VMAP_STACK. In fact x86_32
>>> doesn't have VMAP_STACK at all but can have STACKLEAK.
>>>
>>> [Adding Andy Lutomirski]
>>>
>>> I've made some additional experiments: I exhaust the thread stack to have only
>>> (MIN_STACK_LEFT - 1) bytes left and then force alloca. If VMAP_STACK is
>>> disabled, BUG_ON() handling causes stack depth overflow, which is detected by
>>> SCHED_STACK_END_CHECK. If VMAP_STACK is enabled, the kernel hangs on BUG_ON()
>>> handling! Enabling CONFIG_PROVE_LOCKING gives the needed report from VMAP_STACK:
>
> I can't see why CONFIG_VMAP_STACK would only work in conjunction with
> CONFIG_PROVE_LOCKING.
>
> On arm64 at least, if we overflow the stack while handling a BUG(), we
> *should* trigger the overflow handler as usual, and that should work,
> unless I'm missing something.
>
> Maybe it gets part-way into panic(), sets up some state,
> stack-overflows, and we get wedged because we're already in a panic?
> Perhaps CONFIG_PROVE_LOCKING causes more stack to be used, so it dies a
> little earlier in panic(), before setting up some state that causes
> wedging.
That seems likely. I later noticed that I had oops=panic kernel parameter.
> ... which sounds like something best fixed in those code paths, and not
> here.
>
>> [...]
>>
>>> I can't say why VMAP_STACK report hangs during BUG_ON() handling on defconfig.
>>> Andy, can you give a clue?
>>>
>>> I see that MIN_STACK_LEFT = 2048 is enough for BUG_ON() handling on both x86_64
>>> and x86_32. So I'm going to:
>>> - set MIN_STACK_LEFT to 2048;
>>> - improve the lkdtm test to cover this case.
>>>
>>> Mark, Kees, Laura, does it sound good?
>>
>>
>> Could you have a look at the following changes in check_alloca() before I send
>> the next version?
>>
>> If VMAP_STACK is enabled and alloca causes stack depth overflow, I write to
>> guard page below the thread stack to cause double fault and VMAP_STACK report.
>
> On arm64 at least, writing to the guard page will not itself trigger a
> stack overflow, but will trigger a data abort. I suspect similar is true
> on x86, if the stack pointer is sufficiently far above the guard page.
Yes, you are right, my mistake.
The comment about CONFIG_VMAP_STACK in arch/x86/kernel/traps.c says:
"If we overflow the stack into a guard page, the CPU will fail to deliver #PF
and will send #DF instead."
>> If VMAP_STACK is disabled, I use MIN_STACK_LEFT = 2048, which seems to be enough
>> for BUG_ON() handling both on x86_32 and x86_64. Unfortunately, I can't
>> guarantee that it is always enough.
>
> I don't think that we can choose something that's guaranteed to be
> sufficient for BUG() handling and also not wasting a tonne of space
> under normal operation.
>
> Let's figure out what's going wrong on x86 in the case that you mention,
> and try to solve that.
>
> Here I don't think we should reserve space at all -- it's completely
> arbitrary, and as above we can't guarantee that it's sufficient anyway.
>
>> #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> -#define MIN_STACK_LEFT 256
>> +#define MIN_STACK_LEFT 2048
>>
>> void __used check_alloca(unsigned long size)
>> {
>> unsigned long sp = (unsigned long)&sp;
>> struct stack_info stack_info = {0};
>> unsigned long visit_mask = 0;
>> unsigned long stack_left;
>>
>> BUG_ON(get_stack_info(&sp, current, &stack_info, &visit_mask));
>>
>> stack_left = sp - (unsigned long)stack_info.begin;
>> +
>> +#ifdef CONFIG_VMAP_STACK
>> + /*
>> + * If alloca oversteps the thread stack boundary, we touch the guard
>> + * page provided by VMAP_STACK to trigger handle_stack_overflow().
>> + */
>> + if (size >= stack_left)
>> + *(stack_info.begin - 1) = 42;
>> +#else
>
> On arm64, this won't trigger our stack overflow handler, unless the SP
> is already very close to the boundary.
>
> Please just use BUG(). If there is an issue on x86, it would be good to
> solve that in the x86 code.
>
>> BUG_ON(stack_left < MIN_STACK_LEFT ||
>> size >= stack_left - MIN_STACK_LEFT);
>
> I really don't think we should bother with this arbitrary offset at all.
Thanks. I agree with all your points.
I wrote a third lkdtm test for STACKLEAK which runs deep recursion with alloca.
If I have just BUG_ON(size >= stack_left) in check_alloca(), I get the following
nice report without any trouble:
[ 8.407261] lkdtm: Performing direct entry STACKLEAK_RECURSION_WITH_ALLOCA
[ 8.408641] lkdtm: checking unused part of the thread stack (15744 bytes)...
[ 8.409936] lkdtm: first 744 bytes are unpoisoned
[ 8.410751] lkdtm: the rest of the thread stack is properly erased
[ 8.411760] lkdtm: try to overflow the thread stack using recursion & alloca
[ 8.412914] BUG: stack guard page was hit at 00000000b993c2bc (stack is 00000000764adcd4..000000005b443f11)
[ 8.414471] kernel stack overflow (double-fault): 0000 [#1] SMP PTI
[ 8.415409] Dumping ftrace buffer:
[ 8.415907] (ftrace buffer empty)
[ 8.416404] Modules linked in: lkdtm
[ 8.416905] CPU: 0 PID: 2664 Comm: sh Not tainted 4.17.0-rc3+ #39
[ 8.417766] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 8.419088] RIP: 0010:do_error_trap+0x31/0x130
[ 8.419647] RSP: 0018:ffffc900009b3fc0 EFLAGS: 00010046
[ 8.420263] RAX: 0000000000000000 RBX: ffffc900009b4078 RCX: 0000000000000006
[ 8.421322] RDX: ffffffff81fdbe4d RSI: 0000000000000000 RDI: ffffc900009b4078
[ 8.422837] RBP: 0000000000000006 R08: 0000000000000004 R09: 0000000000000000
[ 8.425095] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004
[ 8.427365] R13: ffffffff81fdbe4d R14: 0000000000000000 R15: 0000000000000000
[ 8.430111] FS: 00007f7c340c1700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
[ 8.432515] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8.433132] CR2: ffffc900009b3fb8 CR3: 000000007b330000 CR4: 00000000000006f0
[ 8.433904] Call Trace:
[ 8.434180] invalid_op+0x14/0x20
[ 8.434546] RIP: 0010:check_alloca+0x8e/0xa0
[ 8.434995] RSP: 0018:ffffc900009b4128 EFLAGS: 00010283
[ 8.435555] RAX: 0000000000000128 RBX: 0000000000000190 RCX: 0000000000000001
[ 8.436479] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffffc900009b4128
[ 8.437871] RBP: ffffc900009b4180 R08: 000000000000018f R09: 0000000000000007
[ 8.438661] R10: 0000000000000000 R11: 0000000000000030 R12: ffff88007a626000
[ 8.439433] R13: 0000000001cf5610 R14: 0000000000000020 R15: ffffc900009b7f08
[ 8.440329] ? check_alloca+0x64/0xa0
[ 8.440845] do_alloca+0x20/0x60 [lkdtm]
[ 8.441937] recursion+0xa0/0xd0 [lkdtm]
[ 8.443370] ? vsnprintf+0xf2/0x4b0
[ 8.444289] ? get_stack_info+0x32/0x160
[ 8.445359] ? check_alloca+0x64/0xa0
[ 8.445995] ? do_alloca+0x20/0x60 [lkdtm]
[ 8.446449] recursion+0xbb/0xd0 [lkdtm]
[ 8.446881] ? vsnprintf+0xf2/0x4b0
[ 8.447259] ? get_stack_info+0x32/0x160
[ 8.447693] ? check_alloca+0x64/0xa0
[ 8.448088] ? do_alloca+0x20/0x60 [lkdtm]
[ 8.448539] recursion+0xbb/0xd0 [lkdtm]
...
It seems that previously I was very "lucky" to accidentally have those MIN_STACK_LEFT,
call trace depth and oops=panic together to experience a hang on stack overflow
during BUG().
When I run my test in a loop _without_ VMAP_STACK, I manage to corrupt the neighbour
processes with BUG() handling overstepping the stack boundary. It's a pity, but
I have an idea.
In kernel/sched/core.c we already have:
#ifdef CONFIG_SCHED_STACK_END_CHECK
if (task_stack_end_corrupted(prev))
panic("corrupted stack end detected inside scheduler\n");
#endif
So what would you think if I do the following in check_alloca():
if (size >= stack_left) {
#if !defined(CONFIG_VMAP_STACK) && defined(CONFIG_SCHED_STACK_END_CHECK)
panic("alloca over the kernel stack boundary\n");
#else
BUG();
#endif
I think that fits well to the CONFIG_SCHED_STACK_END_CHECK policy.
Best regards,
Alexander
^ permalink raw reply
* [PATCH 0/2] Disable EtherAVB by default on R8A779{7|8}0 SoCs
From: Simon Horman @ 2018-05-13 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5844eef7-0f5e-6366-4d3d-a3a658e7f988@cogentembedded.com>
On Fri, May 11, 2018 at 11:18:36PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20180511-v4.17-rc4' tag. I'm fixing the issue in the EtherAVB
> device nodes in the R8A779{7|8}0 device trees that missed the "status" prop,
> usually disabling the SoC devices in anticipation that the board device trees
> enable the devices according to their needs. There should be no issues with
> the current R8A779{7|8}0 board device trees, as all of them use EtherAVB
> anyway, so I'm sending the patches generated against the 'devel' branch...
>
> [1/2] arm64: dts: renesas: r8a77970: disable EtherAVB
> [2/2] arm64: dts: renesas: r8a77980: disable EtherAVB
Thanks, applied.
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Simon Horman @ 2018-05-13 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526032802-14376-4-git-send-email-jacopo+renesas@jmondi.org>
On Fri, May 11, 2018 at 12:00:02PM +0200, Jacopo Mondi wrote:
> Describe HDMI input connected to VIN4 interface for R-Car D3 Draak
> development board.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Hi Niklas,
As you reviewed the rest of the series I'm wondering if you're planning
to review this patch too.
^ permalink raw reply
* [PATCH 2/2] arm64: dts: renesas: initial V3HSK board device tree
From: Simon Horman @ 2018-05-13 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50de037c-7560-c261-f96a-f86065674c9b@cogentembedded.com>
On Thu, May 10, 2018 at 09:12:30PM +0300, Sergei Shtylyov wrote:
> Add the initial device tree for the V3H Starter Kit board.
> The board has 1 debug serial port (SCIF0); include support for it,
> so that the serial console can work.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
This looks fine but I will wait to see if there are other reviews before
applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions
From: Masami Hiramatsu @ 2018-05-13 1:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <59CD6F84-9E51-469B-BB67-340A4F376A13@gmail.com>
On Sat, 12 May 2018 10:29:57 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On May 12, 2018 4:31:37 AM PDT, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >Hi Russell,
> >
> >On Tue, 8 May 2018 12:25:03 +0100
> >Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> >
> >> On Fri, May 04, 2018 at 01:14:31PM +0900, Masami Hiramatsu wrote:
> >> > Hi,
> >> >
> >> > This is the 3rd version of bugfix series for kprobes on arm.
> >> > This series fixes 4 different issues which I found.
> >> >
> >> > - Fix to use smp_processor_id() after disabling preemption.
> >> > - Prohibit probing on optimized_callback() for avoiding
> >> > recursive probe.
> >> > - Prohibit kprobes on do_undefinstr() by same reason.
> >> > - Prohibit kprobes on get_user() by same reason.
> >> >
> >> > >From v2, I included another 2 bugfixes (1/4 and 2/4)
> >> > which are not merged yet, and added "Cc: stable at vger.kernel.org",
> >> > since there are obvious bugs.
> >>
> >> Please submit them to the patch system, thanks.
> >
> >Could you tell me what you mean the patch system?
>
> This is in Russell's signature:
>
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
Ah, Thanks!
OK, I'll submit via that system!
>
> --
> Florian
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* [PATCH] ARM: dts: da850-lego-ev3: remove unnecessary gpio-keys properties
From: David Lechner @ 2018-05-12 21:41 UTC (permalink / raw)
To: linux-arm-kernel
This removes the #address-cells and #size-cells properties from the
gpio-keys node in the da850-lego-ev3 device tree. These properties are
not needed since the child nodes don't have a reg property.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850-lego-ev3.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts b/arch/arm/boot/dts/da850-lego-ev3.dts
index d4a131b6a46e..3fe8db69f50c 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -33,8 +33,6 @@
*/
gpio_keys {
compatible = "gpio-keys";
- #address-cells = <1>;
- #size-cells = <0>;
label = "EV3 Brick Buttons";
pinctrl-names = "default";
pinctrl-0 = <&button_bias>;
--
2.17.0
^ permalink raw reply related
* [PATCH 1/2] clk: davinci: pll-dm646x: keep PLL2 SYSCLK1 always enabled
From: David Lechner @ 2018-05-12 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511141037.25250-2-nsekhar@ti.com>
On 05/11/2018 09:10 AM, Sekhar Nori wrote:
> PLL2 SYSCLK1 on DM646x is connected to DDR2 PHY and cannot
> be disabled. Mark it so to prevent unused clock disable
> infrastructure from disabling it.
>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> ---
> drivers/clk/davinci/pll-dm646x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/davinci/pll-dm646x.c b/drivers/clk/davinci/pll-dm646x.c
> index eb96dd72b6b7..5bdf1cb5fda8 100644
> --- a/drivers/clk/davinci/pll-dm646x.c
> +++ b/drivers/clk/davinci/pll-dm646x.c
> @@ -72,7 +72,7 @@ static const struct davinci_pll_clk_info dm646x_pll2_info = {
> .flags = 0,
> };
>
> -SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, 0);
> +SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, SYSCLK_ALWAYS_ENABLED);
>
> int dm646x_pll2_init(struct device *dev, void __iomem *base, struct regmap *cfgchip)
> {
>
FYI, this only applies on top of "clk: davinci: pll: allow dev == NULL".
Not sure if that was intentional.
^ permalink raw reply
* Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework
From: David Lechner @ 2018-05-12 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <45ce3129-4a9e-54d2-e594-49b451571842@ti.com>
On 05/11/2018 10:26 AM, Sekhar Nori wrote:
> Hi David,
>
> On Wednesday 09 May 2018 10:55 PM, David Lechner wrote:
>> This series converts mach-davinci to use the common clock framework.
>>
>> The series works like this, the first 3 patches fix some issues with the clock
>> drivers that have already been accepted into the mainline kernel.
>
> I have not yet looked at the patches, but I got a bunch of W=1 warnings
> and some sparse warnings when building your branch. Please take a look
> at these. Unfortunately the output is mixed between sparse and compiler.
> The "expression using sizeof(void)" can be ignored as its a known issue
> with sparse, I believe.
>
I've started a common-clk-v11 branch on my GitHub that fixes most of these.
Also submitted "clk: davinci: psc-dm355: fix ASP0/1 clkdev lookups" that
fixes a couple more. I've purposely not fixed the davinci_clk_reset_* functions
since there is already a patch that will remove those functions in the future.
I'll wait a bit longer for DT review before re-sending v11 of this series.
^ permalink raw reply
* [PATCH v2] tty: implement led triggers
From: Uwe Kleine-König @ 2018-05-12 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01dcbf5c-70a0-b067-20c3-f99e22ed4512@arm.com>
On Thu, May 10, 2018 at 12:25:21PM +0100, Robin Murphy wrote:
> On 10/05/18 12:14, Pavel Machek wrote:
> > Hi!
> >
> > > > > > @@ -499,6 +500,7 @@ static void flush_to_ldisc(struct work_struct *work)
> > > > > > struct tty_buffer *head = buf->head;
> > > > > > struct tty_buffer *next;
> > > > > > int count;
> > > > > > + unsigned long delay = 50 /* ms */;
> > > > >
> > > > > Comment after the semicolon?
> > > >
> > > > Given that this comment is about the 50 and not the delay member, I
> > > > prefer it before the ;.
> > >
> > > Hmm. I personally find it hard to read and can only find about 30
> > > instances of this comment style (for assignments) in the kernel. And
> > > arguably the comment applies equally well to the delay variable in this
> > > case too.
> >
> > It is not too traditional, but I believe it makes sense....
> >
> > (and yes, I wish we had kernel in Rust, so we could have real units
> > attached to our variables...)
>
> Well, the variable itself could always be named "delay_ms" if it's really
> that important.
FTR: That's what I did for v3.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v3 1/3] leds: triggers: provide led_trigger_register_format()
From: Uwe Kleine-König @ 2018-05-12 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510112229.GE6977@amd>
On Thu, May 10, 2018 at 01:22:29PM +0200, Pavel Machek wrote:
> On Thu 2018-05-10 13:21:01, Pavel Machek wrote:
> > Hi!
> >
> > > This allows one to simplify drivers that provide a trigger with a
> > > non-constant name (e.g. one trigger per device with the trigger name
> > > depending on the device's name).
> > >
> > > Internally the memory the name member of struct led_trigger points to
> > > now always allocated dynamically instead of just taken from the caller.
> > >
> > > The function led_trigger_rename_static() must be changed accordingly and
> > > was renamed to led_trigger_rename() for consistency, with the only user
> > > adapted.
> >
> > Well, I'm not sure if we want to have _that_ many trigger. Trigger
> > interface is going to become.. "interesting".
> >
> > We have 4K limit on total number of triggers. We use rather strange
> > interface to select trigger.
> >
> > > @@ -115,13 +115,13 @@ static int can_led_notifier(struct notifier_block *nb, unsigned long msg,
> > >
> > > if (msg == NETDEV_CHANGENAME) {
> > > snprintf(name, sizeof(name), "%s-tx", netdev->name);
> > > - led_trigger_rename_static(name, priv->tx_led_trig);
> > > + led_trigger_rename(priv->tx_led_trig, name);
> > >
> > > snprintf(name, sizeof(name), "%s-rx", netdev->name);
> > > - led_trigger_rename_static(name, priv->rx_led_trig);
> > > + led_trigger_rename(priv->rx_led_trig, name);
> > >
> > > snprintf(name, sizeof(name), "%s-rxtx", netdev->name);
> > > - led_trigger_rename_static(name, priv->rxtx_led_trig);
> > > + led_trigger_rename(priv->rxtx_led_trig, name);
> > > }
> > >
> >
> > I know this is not your fault, but if you have a space or "[]" in
> > netdev names, confusing things will happen.
>
> Hmm. If we are doing this we really should check trigger names for
> forbidden characters. At least "[] " should be forbidden.
I think you don't expect me to change the patch, but to make this
explicit: My patch doesn't make this problem worse, so this would be an
orthogonal change and doesn't affect this one.
Spaces don't seem to be allowed in netdev names:
uwe at taurus:~$ sudo ip link set wlp3s0 name 'la la'
Error: argument "la la" is wrong: "name" not a valid ifname
(Didn't check if only ip forbids that, of if that is a kernel policy.) I
could rename my device to "lala[]" though.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] arm64: defconfig: Increase CMA size for VC4
From: Florian Fainelli @ 2018-05-12 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1763641548.255653.1526116226370@email.1und1.de>
On May 12, 2018 2:10:26 AM PDT, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>Hi Florian,
>
>> Eric Anholt <eric@anholt.net> hat am 3. Mai 2018 um 23:20
>geschrieben:
>>
>>
>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>
>> > The VC4 needs more memory than the default setting (16 MB):
>> >
>> > vc4-drm soc:gpu: swiotlb: coherent allocation failed,
>size=16777216
>> > [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
>> > vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning:
>-12.
>> > You may need to enable CMA or give it more memory.
>> > vc4-drm soc:gpu: failed to bind 3fc00000.v3d (ops vc4_v3d_ops
>[vc4]): -12
>> > vc4-drm soc:gpu: master bind failed: -12
>> > vc4-drm: probe of soc:gpu failed with error -12
>> >
>> > So increase the value to 32 MB and fix this issue.
>> >
>> > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>
>> If there was a way to check how big the CMA pool is, then we could
>> probably have V3D disable itself when the pool was too small. It's
>not
>> like V3D rendering is going to actually *work* with just a 32mb pool
>to
>> play in.
>>
>> That said, I'd also be fine with this patch.
>
>should i rebase my patch?
I was expecting Eric to pick it up, but I can do this as well sorry about the miscommunication here. Let me queue this up and update the defconfig-arm64 pull request with this commit.
--
Florian
^ permalink raw reply
* [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions
From: Florian Fainelli @ 2018-05-12 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180512203137.4c00f301c4359de1f6253154@kernel.org>
On May 12, 2018 4:31:37 AM PDT, Masami Hiramatsu <mhiramat@kernel.org> wrote:
>Hi Russell,
>
>On Tue, 8 May 2018 12:25:03 +0100
>Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
>
>> On Fri, May 04, 2018 at 01:14:31PM +0900, Masami Hiramatsu wrote:
>> > Hi,
>> >
>> > This is the 3rd version of bugfix series for kprobes on arm.
>> > This series fixes 4 different issues which I found.
>> >
>> > - Fix to use smp_processor_id() after disabling preemption.
>> > - Prohibit probing on optimized_callback() for avoiding
>> > recursive probe.
>> > - Prohibit kprobes on do_undefinstr() by same reason.
>> > - Prohibit kprobes on get_user() by same reason.
>> >
>> > >From v2, I included another 2 bugfixes (1/4 and 2/4)
>> > which are not merged yet, and added "Cc: stable at vger.kernel.org",
>> > since there are obvious bugs.
>>
>> Please submit them to the patch system, thanks.
>
>Could you tell me what you mean the patch system?
This is in Russell's signature:
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
--
Florian
^ permalink raw reply
* [PATCH] [stable 4.9] arm64: Add work around for Arm Cortex-A55 Erratum 1024718
From: Greg KH @ 2018-05-12 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <843d0226-f715-6a09-276f-ef14d5a06185@arm.com>
On Fri, May 11, 2018 at 05:06:20PM +0100, Suzuki K Poulose wrote:
> On 11/05/18 16:47, Greg KH wrote:
> > On Fri, May 11, 2018 at 02:51:15PM +0100, Suzuki K Poulose wrote:
> > > commit ece1397cbc89c51914fae1aec729539cfd8bd62b upstream
> > >
> > > Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
> > > from an erratum 1024718, which causes incorrect updates when DBM/AP
> > > bits in a page table entry is modified without a break-before-make
> > > sequence. The work around is to disable the hardware DBM feature
> > > on the affected cores. The hardware Access Flag management features
> > > is not affected.
> > >
> > > The hardware DBM feature is a non-conflicting capability, i.e, the
> > > kernel could handle cores using the feature and those without having
> > > the features running at the same time. So this work around is detected
> > > at early boot time, rather than delaying it until the CPUs are brought
> > > up into the kernel with MMU turned on. This also avoids other complexities
> > > with late CPUs turning online, with or without the hardware DBM features.
> > >
> > > Cc: stable at vger.kernel.org # v4.9
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Will Deacon <will.deacon@arm.com>
> > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > > ---
> > > Note: The upstream commit is on top of a reworked capability
> > > infrastructure for arm64 heterogeneous systems, which allows
> > > delaying the CPU model checks. This backport is based on the
> > > original version of the patch [0], which checks the affected
> > > CPU models during the early boot.
> > >
> > > [0] https://lkml.kernel.org/r/20180116102323.3470-1-suzuki.poulose at arm.com
> >
> > Now applied, thanks.
>
> Greg,
>
> I have the backport for v4.4 ready. But it needs to cherry-pick a commit
> (commit 30b5ba5cf33 : arm64: introduce mov_q macro to move a constant into a 64-bit register)
> which adds the assembly helper and that seems to result in a conflict with
> an obvious resolution. What do you prefer in this case ?
>
> 1) Go ahead with the cherry-pick
Have 2 patches, the first be the cherry pick and the second be your
backported other patch. I almost always want the original patches that
are in Linus's tree, otherwise we always get the
merging/squashing/rewrite wrong.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v1 04/13] soc: rockchip: power-domain: Fix wrong value when power up pd
From: Heiko Stuebner @ 2018-05-12 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526009458-28579-5-git-send-email-zhangqing@rock-chips.com>
Hi Elaine,
Am Freitag, 11. Mai 2018, 05:30:49 CEST schrieb Elaine Zhang:
please provide a patch description. This seems to affect rk3328
alone right now, but seems that rk3328 could only ever turn off
power-domains but never turn them on again, right?
Authorship comment from my previous comment applies here
as well.
And please add a
Fixes: 9bb17ce8edb3 ("soc: rockchip: power-domain: Support domain control in hiword-registers")
Cc: stable at vger.kernel.org
to the patch description.
Thanks
Heiko
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
> ---
> drivers/soc/rockchip/pm_domains.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
> index ebd7c41898c0..01d4ba26a054 100644
> --- a/drivers/soc/rockchip/pm_domains.c
> +++ b/drivers/soc/rockchip/pm_domains.c
> @@ -264,7 +264,7 @@ static void rockchip_do_pmu_set_power_domain(struct rockchip_pm_domain *pd,
> return;
> else if (pd->info->pwr_w_mask)
> regmap_write(pmu->regmap, pmu->info->pwr_offset,
> - on ? pd->info->pwr_mask :
> + on ? pd->info->pwr_w_mask :
> (pd->info->pwr_mask | pd->info->pwr_w_mask));
> else
> regmap_update_bits(pmu->regmap, pmu->info->pwr_offset,
>
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77970: add SMP support
From: Simon Horman @ 2018-05-12 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <110ba99c-1a8d-98a1-3ca0-5fc99e79572b@cogentembedded.com>
On Thu, May 10, 2018 at 07:43:03PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 05/09/2018 10:05 PM, Simon Horman wrote:
>
> >>>> Add the device node for the second Cortex-A53 CPU core.
> >>>>
> >>>> Based on the original (and large) patch by Daisuke Matsushita
> >>>> <daisuke.matsushita.ns@hitachi.com>.
> >>>>
> >>>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> >>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >>>
> >>> Dupe of https://patchwork.kernel.org/patch/10032875/
> >>
> >> Sorry!
> >> Not an exact dupe, though -- mine has clock/power #define's used,
> >> yours -- only bare #s. :-)
> >>
> >>> From series "[PATCH 0/2] arm64: dts: renesas: r8a77970: Add SMP Support"
> >>> (https://www.spinics.net/lists/linux-renesas-soc/msg19681.html)
> >>
> >> Hmm... what's the fate of this series?
> >
> > There is now a v2 of Geert's series which incorporates your enhancements.
>
> I suggested to respin it. :-)
Thanks, that would have been my suggestion too :)
> > I will apply that.
>
> Thank you.
> For the record, I had better luck than Geert testing SMP on Eagle:
> only CPU0 couldn't be offlined (and I was unable to find a
> workaround), others could be on/ offlined w/o issues. As for
> suspend/resume -- it did work but I could only test s2idle
> (/sys/power/mem_sleep had no other variants)...
Thanks. Perhaps you have a more recent firmware than Geert.
I would expect the CPU0 issue you describe will be resolved in time in
the firmware.
^ permalink raw reply
* Difference between IOVA and bus address when SMMU is enabled
From: valmiki @ 2018-05-12 12:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi All,
What is the difference between IOVA address and bus address
when SMMU is enabled ?
Is IOVA address term used only when hypervisor is present ?
Regards,
Valmiki
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ 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