Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v1] char: hw_random: atmel-rng: disable TRNG during suspend
From: Wenyou Yang @ 2016-10-24  8:03 UTC (permalink / raw)
  To: linux-arm-kernel

To fix the over consumption on the VDDCore due to the TRNG enabled,
disable the TRNG during suspend, not only disable the user interface
clock (which is controlled by PMC). Because the user interface clock
is independent from any clock that may be used in the entropy source
logic circuitry.

Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---

 drivers/char/hw_random/atmel-rng.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/char/hw_random/atmel-rng.c b/drivers/char/hw_random/atmel-rng.c
index 0fcc9e6..2e2d09a 100644
--- a/drivers/char/hw_random/atmel-rng.c
+++ b/drivers/char/hw_random/atmel-rng.c
@@ -48,6 +48,16 @@ static int atmel_trng_read(struct hwrng *rng, void *buf, size_t max,
 		return 0;
 }
 
+static void atmel_trng_enable(struct atmel_trng *trng)
+{
+	writel(TRNG_KEY | 1, trng->base + TRNG_CR);
+}
+
+static void atmel_trng_disable(struct atmel_trng *trng)
+{
+	writel(TRNG_KEY, trng->base + TRNG_CR);
+}
+
 static int atmel_trng_probe(struct platform_device *pdev)
 {
 	struct atmel_trng *trng;
@@ -71,7 +81,7 @@ static int atmel_trng_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	writel(TRNG_KEY | 1, trng->base + TRNG_CR);
+	atmel_trng_enable(trng);
 	trng->rng.name = pdev->name;
 	trng->rng.read = atmel_trng_read;
 
@@ -94,7 +104,7 @@ static int atmel_trng_remove(struct platform_device *pdev)
 
 	hwrng_unregister(&trng->rng);
 
-	writel(TRNG_KEY, trng->base + TRNG_CR);
+	atmel_trng_disable(trng);
 	clk_disable_unprepare(trng->clk);
 
 	return 0;
@@ -105,6 +115,7 @@ static int atmel_trng_suspend(struct device *dev)
 {
 	struct atmel_trng *trng = dev_get_drvdata(dev);
 
+	atmel_trng_disable(trng);
 	clk_disable_unprepare(trng->clk);
 
 	return 0;
@@ -114,6 +125,7 @@ static int atmel_trng_resume(struct device *dev)
 {
 	struct atmel_trng *trng = dev_get_drvdata(dev);
 
+	atmel_trng_enable(trng);
 	return clk_prepare_enable(trng->clk);
 }
 
-- 
2.7.4

^ permalink raw reply related

* [PATCH v2] drivers: psci: PSCI checker module
From: Geert Uytterhoeven @ 2016-10-24  8:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <2e2dedf4-192f-8657-10b1-24b426af5f00@arm.com>

On Thu, Oct 20, 2016 at 4:21 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 20/10/16 14:38, Kevin Brodsky wrote:
>
> [...]
>
>>
>> Thanks for the heads-up! I'll rebase on 4.9-rc1 and see what needs to be
>> done.
>>
>
> Just be aware that v4.9-rc1 doesn't have commit 9cfb38a7ba5a
> ("sched/fair: Fix sched domains NULL dereference in
> select_idle_sibling()") which fixes the cpuhotplug issue you would
> observe.

Good to know. I saw that issue during resume from s2ram on r8a7795/Salvator-X
once, but couldn't reproduce it.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* [PATCH] arm/arm64: KVM: Map the BSS at HYP
From: Christoffer Dall @ 2016-10-24  8:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1476968441-29003-1-git-send-email-marc.zyngier@arm.com>

On Thu, Oct 20, 2016 at 02:00:41PM +0100, Marc Zyngier wrote:
> When used with a compiler that doesn't implement "asm goto"
> (such as the AArch64 port of GCC 4.8), jump labels generate a
> memory access to find out about the value of the key (instead
> of just patching the code). The key itself is likely to be
> stored in the BSS.
> 
> This is perfectly fine, except that we don't map the BSS at HYP,
> leading to an exploding kernel at the first access. The obvious
> fix is simply to map the BSS there (which should have been done
> a long while ago, but hey...).
> 
> Reported-by: Eric Auger <eric.auger@redhat.com>
> Tested-by: Eric Auger <eric.auger@redhat.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

Acked-by: Christoffer Dall <christoffer.dall@linaro.org>

^ permalink raw reply

* Disabling an interrupt in the handler locks the system up
From: Marc Zyngier @ 2016-10-24  8:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <580BF1D4.2030509@free.fr>

On 23/10/16 00:10, Mason wrote:
> On 22/10/2016 13:37, Marc Zyngier wrote:
> 
>> Mason wrote:
>>
>>> In my mental picture of interrupts (which is obviously so
>>> incomplete as to be wrong) interrupts are a way for hardware
>>> to tell the CPU that they urgently need the CPU's attention.
>>
>> That's how the CPU interprets it, but this is even more basic than
>> that, see below.
>>
>>> Obviously, the hardware being idle (line high) is not an urgent
>>> matter which interests the CPU. Likewise, I'm not sure the CPU
>>> cares that the hardware is busy (line low). It seems to me the
>>> interesting event from the CPU's perspective is when the
>>> hardware completes a "task" (transition from low to high).
>>
>> There is no such thing as "busy" when it comes to interrupts. An
>> interrupt signals the CPU that some device-specific condition has been
>> satisfied. It could be "I've received a packet" or "Battery is about to
>> explode", depending if the device is a network controller or a
>> temperature sensor. The interrupt doesn't describe the process that
>> leads to that condition (packet being received or temperature rising),
>> but the condition itself.
>>
>> In your cases, as the device seems to do some form of processing
>> (you're talking about task completion), then the interrupt seems to
>> describe exactly this ("I'm done").
> 
> The device is a graphics engine, which can be programmed to perform
> some operation on one or several frame buffers stored in memory.
> It outputs its state (idle vs busy) on interrupt line 23.
> 
>>> So I had originally configured the interrupt as IRQ_TYPE_EDGE_RISING.
>>> (There is an edge detection block in the irqchip, but the HW designer
>>> warned me that at low frequencies, it is possible to "miss" some edges,
>>> and we should prefer level triggers if possible.)
>>
>> Level and edge are not interchangeable. They do describe very different
>> thing:
>>
>> - Level indicates a persistent state, which implies that the device
>>   needs to be serviced so that this condition can be cleared (the UART
>>   has received a character, and won't be able to received another until
>>   it has been read by the CPU). Once the device has been serviced and
>>   that condition cleared, it will lower its interrupt line.
> 
> With this graphics engine, there is nothing the CPU can do to
> change what the engine outputs on the interrupt line:
> 
> When the graphics engine is idle, the line remains high, forever.
> When the graphics engine is busy, the line remains low, until
> all operations have been performed (engine idle).
> 
> All the CPU can do is mask the interrupt line at the interrupt
> controller, as far as I understand.

Then this is unambiguously a rising edge interrupt.

> 
>> - Edge is indicative of an event having occurred ("I'm done") that
>>   doesn't require any action from the CPU. Because the device can
>>   continue its life without being poked by the CPU, it can continue
>>   delivering interrupts even if the first one hasn't been serviced.
>>   Being edge triggered, the signals get coalesced into a single
>>   interrupt. For example, the temperature sensor will say "Temperature
>>   rising" multiple times before the battery explodes, and it is the
>>   CPU's job to go and read the sensor to find out by how much it has
>>   risen.
>>
>> If your device only sends a pulse, then it is edge triggered, and it
>> should be treated as such, no matter what your HW guy is saying. This
>> usually involves looking at the device to find out how many times the
>> interrupt has been generated (assuming the device is some kind of
>> processing element). Of course, this is racy (interrupts can still be
>> generated whilst you're processing them), and you should design your
>> interrupt handler to take care of the possible race.
> 
> It is clear that the block does not send a pulse on the
> interrupt line.
> 
> For reasons I don't understand, Linux didn't hang when I set
> the IRQ type to IRQ_TYPE_EDGE_RISING, so it seemed better
> than locking up the system.

Because that's exactly what that is.

> 
> I'm also fuzzy on what purpose the edge detector is supposed
> to serve... I had the impression is what supposed to "capture"
> an edge, to turn it into a level?

If you care to read the explanation I've given above, you'll realize
that you cannot turn an edge into a level, because they don't represent
the same thing (state vs event). The interrupt controller will latch on
a rising edge (for example), and present that information to the CPU, no
matter what the line does after that.

>> So, to make it short: find out how your device works, and configure
>> your interrupt controller in a similar way. Write your device driver
>> with the interrupt policy in mind (state vs event). Keep it simple.
> 
> Thomas said "We describe the level which is raising the interrupt".
> But I'm not sure I want the state "engine is busy" to raise an
> interrupt. "engine is idle" makes more sense. But you said it's
> stupid to set IRQ_TYPE_LEVEL_HIGH... /me confused

Because you insist on considering as a level something that is an edge.
Once you try to understand the nature of the signal the device is
providing, then you may stop getting confused.

You definitely don't want to generate an interrupt when the device is
idle, because that's a state on which you cannot act (apart from
constantly generating job for your graphics engine). What you want to
detect is the *transition* from busy to idle (event). Nothing else matters.

> Maybe the fact that disable_irq locks the system up is an orthogonal
> issue that needs to be fixed anyway.

Indeed.

	M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply

* [PATCH 1/3] phy: sun4i: check PHY id when poking unknown bit of pmu
From: Maxime Ripard @ 2016-10-24  8:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161024035930.20274-1-icenowy@aosc.xyz>

On Mon, Oct 24, 2016 at 11:59:30AM +0800, Icenowy Zheng wrote:
> Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
> The code that poke some unknown bit of PMU for H3/A64 didn't check
> the PHY, and will cause kernel oops when PHY 0 is used.
> 
> Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>

Cc'ing stable would be nice.

Apart from that, Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/a0929938/attachment.sig>

^ permalink raw reply

* [PATCH 1/3] ARM: dts: hip01: Remove skeleton.dtsi inclusion
From: Kefeng Wang @ 2016-10-24  8:31 UTC (permalink / raw)
  To: linux-arm-kernel

Since commit 9c0da3cc61f1233c ("ARM: dts: explicitly mark skeleton.dtsi
as deprecated"), remove deprecated skeleton.dtsi.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
 arch/arm/boot/dts/hip01.dtsi | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/hip01.dtsi b/arch/arm/boot/dts/hip01.dtsi
index 4e9562f..9d5fd5c 100644
--- a/arch/arm/boot/dts/hip01.dtsi
+++ b/arch/arm/boot/dts/hip01.dtsi
@@ -11,8 +11,6 @@
  * published by the Free Software Foundation.
  */
 
-#include "skeleton.dtsi"
-
 / {
 	interrupt-parent = <&gic>;
 	#address-cells = <1>;
-- 
1.7.12.4

^ permalink raw reply related

* [PATCH 2/3] ARM: dts: hi3620: Remove skeleton.dtsi inclusion
From: Kefeng Wang @ 2016-10-24  8:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477297890-34899-1-git-send-email-wangkefeng.wang@huawei.com>

Since commit 9c0da3cc61f1233c ("ARM: dts: explicitly mark skeleton.dtsi
as deprecated"), remove deprecated skeleton.dtsi.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
 arch/arm/boot/dts/hi3620.dtsi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/hi3620.dtsi b/arch/arm/boot/dts/hi3620.dtsi
index c85d07e..d18a915 100644
--- a/arch/arm/boot/dts/hi3620.dtsi
+++ b/arch/arm/boot/dts/hi3620.dtsi
@@ -11,10 +11,12 @@
  * publishhed by the Free Software Foundation.
  */
 
-#include "skeleton.dtsi"
 #include <dt-bindings/clock/hi3620-clock.h>
 
 / {
+	#address-cells = <1>;
+	#size-cells = <1>;
+
 	aliases {
 		serial0 = &uart0;
 		serial1 = &uart1;
-- 
1.7.12.4

^ permalink raw reply related

* [PATCH 3/3] ARM: dts: hisi-x5hd2: Remove skeleton.dtsi inclusion
From: Kefeng Wang @ 2016-10-24  8:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477297890-34899-1-git-send-email-wangkefeng.wang@huawei.com>

Since commit 9c0da3cc61f1233c ("ARM: dts: explicitly mark skeleton.dtsi
as deprecated"), remove deprecated skeleton.dtsi.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
 arch/arm/boot/dts/hisi-x5hd2.dtsi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index fdcc23d..506fdc1 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -7,10 +7,12 @@
  * publishhed by the Free Software Foundation.
  */
 
-#include "skeleton.dtsi"
 #include <dt-bindings/clock/hix5hd2-clock.h>
 
 / {
+	#address-cells = <1>;
+	#size-cells = <1>;
+
 	aliases {
 		serial0 = &uart0;
 	};
-- 
1.7.12.4

^ permalink raw reply related

* [PATCH 1/3] arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
From: Marc Zyngier @ 2016-10-24  8:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <962ea92f-870b-e1d0-5bb7-1a6d66c35122@huawei.com>

On 23/10/16 04:21, Ding Tianhong wrote:
> This erratum describes a bug in logic outside the core, so MIDR can't be
> used to identify its presence, and reading an SoC-specific revision
> register from common arch timer code would be awkward.  So, describe it
> in the device tree.
> 
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
>  Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
> index ef5fbe9..26bc837 100644
> --- a/Documentation/devicetree/bindings/arm/arch_timer.txt
> +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
> @@ -31,6 +31,12 @@ to deliver its interrupts via SPIs.
>    This also affects writes to the tval register, due to the implicit
>    counter read.
> 
> +- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of
> +  QorIQ erratum 161201, which says that reading the counter is

Other than the copy/paste of the FSL erratum, please document the actual
erratum number. Is that 161x01 or 161201?

> +  unreliable unless the small range of value is returned by back-to-back reads.

That's a detail that doesn't belong in the DT, but that would be much
better next to the code doing the actual handling.

> +  This also affects writes to the tval register, due to the implicit
> +  counter read.
> +
>  ** Optional properties:
> 
>  - arm,cpu-registers-not-fw-configured : Firmware does not initialize
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply

* [PATCH V2 1/5] powerpc/mpc85xx: Update TMU device tree node for T1040/T1042
From: Shawn Guo @ 2016-10-24  8:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475995626-14049-1-git-send-email-hongtao.jia@nxp.com>

On Sun, Oct 09, 2016 at 02:47:02PM +0800, Jia Hongtao wrote:
> From: Hongtao Jia <hongtao.jia@nxp.com>
> 
> SoC compatible string and endianness property are added according to the
> new bindings.

The commit log doesn't seem to match the actual changes.  Same for patch
2/5.

Shawn

> 
> Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>
> ---
> Changes for V2:
> * Rebase on latest linux-next tree (next-20161006).
> 
>  arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
> index 44e399b..145c7f4 100644
> --- a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
> @@ -526,7 +526,7 @@
>  
>  				       0x00030000 0x00000012
>  				       0x00030001 0x0000001d>;
> -		#thermal-sensor-cells = <0>;
> +		#thermal-sensor-cells = <1>;
>  	};
>  
>  	thermal-zones {
> @@ -534,7 +534,7 @@
>  			polling-delay-passive = <1000>;
>  			polling-delay = <5000>;
>  
> -			thermal-sensors = <&tmu>;
> +			thermal-sensors = <&tmu 2>;
>  
>  			trips {
>  				cpu_alert: cpu-alert {
> -- 
> 2.1.0.27.g96db324
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v2 0/3] STM32F429: Add Ethernet fixes
From: Alexandre TORGUE @ 2016-10-24  8:40 UTC (permalink / raw)
  To: linux-arm-kernel

This v2 to avoid build issue when only patch 1 (of first series) 
was build. 

This series adds several fixes for Ethernet for stm32f429 MCU.
First patch has already been reviewed some months ago when 
stm32 Ethernet glue has been pushed (I added in this series to keep
history). Fixes are:
 -Change DT to be compliant to stm32 ethernet glue binding
 -Add phy-handle to correctly use mdio subnode
 -Remove WoL support

changes since v1:
 -squash patch1 and patch2. 

Regards

Alex

Alexandre TORGUE (3):
  ARM: dts: stm32f429: Align Ethernet node with new bindings properties
  ARM: dts: stm32f429: Fix Ethernet node on Eval Board
  ARM: dts: stm32f429: remove Ethernet wake on Lan support

 arch/arm/boot/dts/stm32429i-eval.dts |  7 ++++---
 arch/arm/boot/dts/stm32f429.dtsi     | 10 +++++-----
 2 files changed, 9 insertions(+), 8 deletions(-)

-- 
1.9.1

^ permalink raw reply

* [PATCH v2 1/3] ARM: dts: stm32f429: Align Ethernet node with new bindings properties
From: Alexandre TORGUE @ 2016-10-24  8:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477298406-22805-1-git-send-email-alexandre.torgue@st.com>

This patch aligns clocks names and node reference according to new
stm32-dwmac glue binding. It also renames Ethernet pinctrl phandle
(indeed there is no need to add 0 as Ethernet instance as there is only
one IP in SOC).

Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index 13c7cd2..fa30bf1 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -94,11 +94,12 @@
 	clock-frequency = <25000000>;
 };
 
-&ethernet0 {
+&mac {
 	status = "okay";
-	pinctrl-0	= <&ethernet0_mii>;
+	pinctrl-0	= <&ethernet_mii>;
 	pinctrl-names	= "default";
-	phy-mode	= "mii-id";
+	phy-mode	= "mii";
+
 	mdio0 {
 		#address-cells = <1>;
 		#size-cells = <0>;
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 336ee4f..6350117b 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -313,7 +313,7 @@
 				};
 			};
 
-			ethernet0_mii: mii at 0 {
+			ethernet_mii: mii at 0 {
 				pins {
 					pinmux = <STM32F429_PG13_FUNC_ETH_MII_TXD0_ETH_RMII_TXD0>,
 						 <STM32F429_PG14_FUNC_ETH_MII_TXD1_ETH_RMII_TXD1>,
@@ -373,13 +373,13 @@
 			st,mem2mem;
 		};
 
-		ethernet0: dwmac at 40028000 {
+		mac: ethernet at 40028000 {
 			compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
 			reg = <0x40028000 0x8000>;
 			reg-names = "stmmaceth";
 			interrupts = <61>, <62>;
 			interrupt-names = "macirq", "eth_wake_irq";
-			clock-names = "stmmaceth", "tx-clk", "rx-clk";
+			clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx";
 			clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
 			st,syscon = <&syscfg 0x4>;
 			snps,pbl = <8>;
-- 
1.9.1

^ permalink raw reply related

* [PATCH v2 2/3] ARM: dts: stm32f429: Fix Ethernet node on Eval Board
From: Alexandre TORGUE @ 2016-10-24  8:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477298406-22805-1-git-send-email-alexandre.torgue@st.com>

"phy-handle" entry is mandatory when mdio subnode is used in
Ethernet node.

Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index fa30bf1..a11b108 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -99,7 +99,7 @@
 	pinctrl-0	= <&ethernet_mii>;
 	pinctrl-names	= "default";
 	phy-mode	= "mii";
-
+	phy-handle	= <&phy1>;
 	mdio0 {
 		#address-cells = <1>;
 		#size-cells = <0>;
-- 
1.9.1

^ permalink raw reply related

* [PATCH v2 3/3] ARM: dts: stm32f429: remove Ethernet wake on Lan support
From: Alexandre TORGUE @ 2016-10-24  8:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477298406-22805-1-git-send-email-alexandre.torgue@st.com>

This patch removes WoL (Wake on Lan) support as it is not yet
fully supported and tested.

Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 6350117b..ad0bc6a 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -377,8 +377,8 @@
 			compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
 			reg = <0x40028000 0x8000>;
 			reg-names = "stmmaceth";
-			interrupts = <61>, <62>;
-			interrupt-names = "macirq", "eth_wake_irq";
+			interrupts = <61>;
+			interrupt-names = "macirq";
 			clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx";
 			clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
 			st,syscon = <&syscfg 0x4>;
-- 
1.9.1

^ permalink raw reply related

* mbox-name vs. mbox-names (was: Re: [PATCH v4 1/5] mailbox: dt: Supply bindings for ST's Mailbox IP)
From: Lee Jones @ 2016-10-24  8:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAMuHMdXqOZ=eKJ=SkY4TM=fu8qnZ2gLmh-2iH0jB2pAu_v2vNg@mail.gmail.com>

On Fri, 21 Oct 2016, Geert Uytterhoeven wrote:

> On Fri, Oct 16, 2015 at 9:21 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> >  .../devicetree/bindings/mailbox/sti-mailbox.txt    | 51 ++++++++++++++++++++++
> >  1 file changed, 51 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > new file mode 100644
> > index 0000000..b61eec9
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > @@ -0,0 +1,51 @@
> > +ST Microelectronics Mailbox Driver
> > +
> > +Each ST Mailbox IP currently consists of 4 instances of 32 channels.  Messages
> > +are passed between Application and Remote processors using shared memory.
> > +
> > +Controller
> > +----------
> > +
> > +Required properties:
> > +- compatible           : Should be "st,stih407-mailbox"
> > +- reg                  : Offset and length of the device's register set
> > +- mbox-name            : Name of the mailbox
> 
> All other mailbox drivers use "mbox-names". Oops, it's in v4.9-rc1...
> 
> Can we still fix that?

So long as all the fixes; changes to the driver and DT are merged in a
single kernel release, we can change it.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH 1/3] arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
From: Ding Tianhong @ 2016-10-24  8:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <3a29c03a-2da1-7bfe-28ff-21dada50ee8d@arm.com>



On 2016/10/24 16:36, Marc Zyngier wrote:
> On 23/10/16 04:21, Ding Tianhong wrote:
>> This erratum describes a bug in logic outside the core, so MIDR can't be
>> used to identify its presence, and reading an SoC-specific revision
>> register from common arch timer code would be awkward.  So, describe it
>> in the device tree.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>>  Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
>> index ef5fbe9..26bc837 100644
>> --- a/Documentation/devicetree/bindings/arm/arch_timer.txt
>> +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
>> @@ -31,6 +31,12 @@ to deliver its interrupts via SPIs.
>>    This also affects writes to the tval register, due to the implicit
>>    counter read.
>>
>> +- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of
>> +  QorIQ erratum 161201, which says that reading the counter is
> 
> Other than the copy/paste of the FSL erratum, please document the actual
> erratum number. Is that 161x01 or 161201?
> 

Sorry for the lazy behavior.

>> +  unreliable unless the small range of value is returned by back-to-back reads.
> 
> That's a detail that doesn't belong in the DT, but that would be much
> better next to the code doing the actual handling.
> 
Got it.

Thanks
Ding

>> +  This also affects writes to the tval register, due to the implicit
>> +  counter read.
>> +
>>  ** Optional properties:
>>
>>  - arm,cpu-registers-not-fw-configured : Firmware does not initialize
>>
> 
> Thanks,
> 
> 	M.
> 

^ permalink raw reply

* [PATCH V2 3/5] arm:dt:ls1021a: Add TMU device tree support for LS1021A
From: Shawn Guo @ 2016-10-24  8:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475995626-14049-3-git-send-email-hongtao.jia@nxp.com>

On Sun, Oct 09, 2016 at 02:47:04PM +0800, Jia Hongtao wrote:
> From: Hongtao Jia <hongtao.jia@nxp.com>
> 
> Also add nodes and properties for thermal management support.
> 
> Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>

For patch #3 ~ #5, I updated the subject prefix a bit and applied.

Shawn

^ permalink raw reply

* [PATCH V4 01/10] acpi: apei: read ack upon ghes record consumption
From: Suzuki K Poulose @ 2016-10-24  8:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477071013-29563-2-git-send-email-tbaicar@codeaurora.org>

On 21/10/16 18:30, Tyler Baicar wrote:
> A RAS (Reliability, Availability, Serviceability) controller
> may be a separate processor running in parallel with OS
> execution, and may generate error records for consumption by
> the OS. If the RAS controller produces multiple error records,
> then they may be overwritten before the OS has consumed them.
>
> The Generic Hardware Error Source (GHES) v2 structure
> introduces the capability for the OS to acknowledge the
> consumption of the error record generated by the RAS
> controller. A RAS controller supporting GHESv2 shall wait for
> the acknowledgment before writing a new error record, thus
> eliminating the race condition.
>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> Signed-off-by: Richard Ruigrok <rruigrok@codeaurora.org>
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
> ---
>  drivers/acpi/apei/ghes.c | 42 ++++++++++++++++++++++++++++++++++++++++++
>  drivers/acpi/apei/hest.c |  7 +++++--
>  include/acpi/ghes.h      |  5 ++++-
>  3 files changed, 51 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 60746ef..7d020b0 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -45,6 +45,7 @@
>  #include <linux/aer.h>
>  #include <linux/nmi.h>
>
> +#include <acpi/actbl1.h>
>  #include <acpi/ghes.h>
>  #include <acpi/apei.h>
>  #include <asm/tlbflush.h>
> @@ -79,6 +80,10 @@
>  	((struct acpi_hest_generic_status *)				\
>  	 ((struct ghes_estatus_node *)(estatus_node) + 1))
>
> +#define HEST_TYPE_GENERIC_V2(ghes)				\
> +	((struct acpi_hest_header *)ghes->generic)->type ==	\
> +	 ACPI_HEST_TYPE_GENERIC_ERROR_V2
> +
>  /*
>   * This driver isn't really modular, however for the time being,
>   * continuing to use module_param is the easiest way to remain
> @@ -248,7 +253,15 @@ static struct ghes *ghes_new(struct acpi_hest_generic *generic)
>  	ghes = kzalloc(sizeof(*ghes), GFP_KERNEL);
>  	if (!ghes)
>  		return ERR_PTR(-ENOMEM);
> +
>  	ghes->generic = generic;
> +	if (HEST_TYPE_GENERIC_V2(ghes)) {
> +		rc = apei_map_generic_address(
> +			&ghes->generic_v2->read_ack_register);
> +		if (rc)
> +			goto err_unmap;

I think should be goto err_free, see more below.

> +	}
> +
>  	rc = apei_map_generic_address(&generic->error_status_address);
>  	if (rc)
>  		goto err_free;
> @@ -270,6 +283,9 @@ static struct ghes *ghes_new(struct acpi_hest_generic *generic)
>
>  err_unmap:
>  	apei_unmap_generic_address(&generic->error_status_address);
> +	if (HEST_TYPE_GENERIC_V2(ghes))
> +		apei_unmap_generic_address(
> +			&ghes->generic_v2->read_ack_register);

We might end up trying to unmap (error_status_address) which is not mapped
if we hit the error in mapping read_ack_register. The read_ack_register unmap
hunk should be moved below to err_free.


>  err_free:
>  	kfree(ghes);
>  	return ERR_PTR(rc);
> @@ -279,6 +295,9 @@ static void ghes_fini(struct ghes *ghes)
>  {
>  	kfree(ghes->estatus);
>  	apei_unmap_generic_address(&ghes->generic->error_status_address);
> +	if (HEST_TYPE_GENERIC_V2(ghes))
> +		apei_unmap_generic_address(
> +			&ghes->generic_v2->read_ack_register);
>  }
>
>  static inline int ghes_severity(int severity)
> @@ -648,6 +667,23 @@ static void ghes_estatus_cache_add(
>  	rcu_read_unlock();
>  }
>

> +static int ghes_do_read_ack(struct acpi_hest_generic_v2 *generic_v2)

nit: We are actually writing something to the read_ack_register. The names
read_ack_register (which may be as per standard) and more importantly the
function name (ghes_do_read_ack) sounds a bit misleading.

Rest looks fine to me.

Suzuki

^ permalink raw reply

* [PATCH] ARM: sti: stih410-clocks: Add PROC_STFE as a critical clock
From: Lee Jones @ 2016-10-24  8:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1476804957-24000-1-git-send-email-peter.griffin@linaro.org>

On Tue, 18 Oct 2016, Peter Griffin wrote:

> Once the ST frontend demux HW IP has been enabled, the clock can't
> be disabled otherwise the system will hang and the board will
> be unserviceable.
> 
> To allow balanced clock enable/disable calls in the driver we use
> the critical clock infrastructure to take an extra reference on the
> clock so the clock will never actually be disabled.

This is an abuse of the critical-clocks framework, and is exactly the
type of hack I promised the clk guys I'd try to prevent.  If this, or
any other IP has some quirks (i.e. once enabled, if this clock is
subsequently disabled it will have a catastrophic effect on the
platform), then they should be worked around in the driver.

The correct thing to do here is craft a clk-keep-on flag and ensure it
is set to true for the effected platform(s)' platform data.

> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih410-clock.dtsi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/stih410-clock.dtsi b/arch/arm/boot/dts/stih410-clock.dtsi
> index 8598eff..07c8ef9 100644
> --- a/arch/arm/boot/dts/stih410-clock.dtsi
> +++ b/arch/arm/boot/dts/stih410-clock.dtsi
> @@ -208,7 +208,8 @@
>  						     "clk-clust-hades",
>  						     "clk-hwpe-hades",
>  						     "clk-fc-hades";
> -				clock-critical = <CLK_ICN_CPU>,
> +				clock-critical = <CLK_PROC_STFE>,
> +						 <CLK_ICN_CPU>,
>  						 <CLK_TX_ICN_DMU>,
>  						 <CLK_EXT2F_A9>,
>  						 <CLK_ICN_LMI>,

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* Build regressions/improvements in v4.9-rc2
From: Geert Uytterhoeven @ 2016-10-24  8:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477298556-1522-1-git-send-email-geert@linux-m68k.org>

On Mon, Oct 24, 2016 at 10:42 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v4.9-rc2[1] to v4.9-rc1[3], the summaries are:
>   - build errors: +10/-21

  + /home/kisskb/slave/src/arch/arm/include/asm/dma-mapping.h: error:
invalid suffix "xUL" on integer constant:  => 84:1
  + /home/kisskb/slave/src/include/linux/dma-mapping.h: error: invalid
suffix "xUL" on integer constant:  => 190:1, 193:1
  + /home/kisskb/slave/src/include/linux/mm.h: error: invalid suffix
"xUL" on integer constant:  => 555:1
  + /home/kisskb/slave/src/include/linux/scatterlist.h: error: invalid
suffix "xUL" on integer constant:  => 142:1

arm-randconfig

Not a new problem. Real issue is "CONFIG_PAGE_OFFSET=" in .config,
leading to:

    ./include/generated/autoconf.h:1113:28: error: invalid suffix
"xUL" on integer constant
     #define CONFIG_PAGE_OFFSET 0x

Why is CONFIG_PAGE_OFFSET empty?

    scripts/kconfig/conf  --oldconfig Kconfig
    .config:316:warning: symbol value '' invalid for PAGE_OFFSET

config PAGE_OFFSET
        hex
        default PHYS_OFFSET if !MMU

# CONFIG_MMU is not set
but CONFIG_PHYS_OFFSET does not exist in .config??

config PHYS_OFFSET
        hex "Physical address of main memory" if MMU
        depends on !ARM_PATCH_PHYS_VIRT
        default DRAM_BASE if !MMU
        default 0x00000000 if ARCH_EBSA110 || \
                        ARCH_FOOTBRIDGE || \
                        ARCH_INTEGRATOR || \
                        ARCH_IOP13XX || \
                        ARCH_KS8695 || \
                        ARCH_REALVIEW
        default 0x10000000 if ARCH_OMAP1 || ARCH_RPC
        default 0x20000000 if ARCH_S5PV210
        default 0xc0000000 if ARCH_SA1100
        help
          Please provide the physical address corresponding to the
          location of main memory in your system.

CONFIG_DRAM_BASE=0x00800000

Aha, CONFIG_ARM_PATCH_PHYS_VIRT=y

> [1] http://kisskb.ellerman.id.au/kisskb/head/11104/ (all 262 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/11053/ (all 262 configs)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* [PATCH v2 2/2] arm64: dts: zx: Add clock controller nodes
From: Shawn Guo @ 2016-10-24  8:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161017204841.GD3264@localhost>

On Mon, Oct 17, 2016 at 01:48:41PM -0700, Olof Johansson wrote:
> On Thu, Oct 13, 2016 at 08:31:21PM +0800, Jun Nie wrote:
> > Add clock controller nodes, including one top controller
> > two low speed controllers and one audio controller.
> > 
> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > ---
> >  arch/arm64/boot/dts/zte/zx296718.dtsi | 24 ++++++++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> 
> This isn't a fix for a bug, so please send this with your other updates for
> v4.10.

I queued it up for 4.10.

Shawn

^ permalink raw reply

* [PATCH v2] drivers: psci: PSCI checker module
From: Sudeep Holla @ 2016-10-24  8:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAMuHMdVgccJ0A2d_-uU+8r0h-NBeet3eGkKq14eaFo34ydqtzQ@mail.gmail.com>



On 24/10/16 09:09, Geert Uytterhoeven wrote:
> On Thu, Oct 20, 2016 at 4:21 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 20/10/16 14:38, Kevin Brodsky wrote:
>>
>> [...]
>>
>>>
>>> Thanks for the heads-up! I'll rebase on 4.9-rc1 and see what needs to be
>>> done.
>>>
>>
>> Just be aware that v4.9-rc1 doesn't have commit 9cfb38a7ba5a
>> ("sched/fair: Fix sched domains NULL dereference in
>> select_idle_sibling()") which fixes the cpuhotplug issue you would
>> observe.
>
> Good to know. I saw that issue during resume from s2ram on r8a7795/Salvator-X
> once, but couldn't reproduce it.
>

Did you try v4.9-rc1 itself ? The above commit is present post -rc1 and
must be in -rc2. I can consistently see the crash without the commit.

-- 
Regards,
Sudeep

^ permalink raw reply

* [PATCH v2] drivers: psci: PSCI checker module
From: Geert Uytterhoeven @ 2016-10-24  9:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <80506636-d4a1-9a1b-4169-d153326b54aa@arm.com>

Hi Sudeep,

On Mon, Oct 24, 2016 at 10:57 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 24/10/16 09:09, Geert Uytterhoeven wrote:
>> On Thu, Oct 20, 2016 at 4:21 PM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:
>>> On 20/10/16 14:38, Kevin Brodsky wrote:
>>>
>>> [...]
>>>
>>>>
>>>> Thanks for the heads-up! I'll rebase on 4.9-rc1 and see what needs to be
>>>> done.
>>>>
>>>
>>> Just be aware that v4.9-rc1 doesn't have commit 9cfb38a7ba5a
>>> ("sched/fair: Fix sched domains NULL dereference in
>>> select_idle_sibling()") which fixes the cpuhotplug issue you would
>>> observe.
>>
>>
>> Good to know. I saw that issue during resume from s2ram on
>> r8a7795/Salvator-X
>> once, but couldn't reproduce it.
>>
>
> Did you try v4.9-rc1 itself ? The above commit is present post -rc1 and
> must be in -rc2. I can consistently see the crash without the commit.

I used a tree based on v4.9-rc1, not including commit 9cfb38a7ba5a.
Will try v4.9-rc2 shortly...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* [PATCH v5 3/9] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
From: Mauro Carvalho Chehab @ 2016-10-24  9:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477279328.10501.10.camel@mtksdaap41>

Em Mon, 24 Oct 2016 11:22:08 +0800
Tiffany Lin <tiffany.lin@mediatek.com> escreveu:

> Hi Mauro,
> 
> On Fri, 2016-10-21 at 11:01 -0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 2 Sep 2016 20:19:54 +0800
> > Tiffany Lin <tiffany.lin@mediatek.com> escreveu:
> >   
> > > Add v4l2 layer decoder driver for MT8173
> > > 
> > > Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com>  
> >   
> > > +int vdec_if_init(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
> > > +{
> > > +	int ret = 0;
> > > +
> > > +	switch (fourcc) {
> > > +	case V4L2_PIX_FMT_H264:
> > > +	case V4L2_PIX_FMT_VP8:
> > > +	default:
> > > +		return -EINVAL;
> > > +	}  
> > 
> > Did you ever test this driver? The above code will *always* return
> > -EINVAL, with will cause vidioc_vdec_s_fmt() to always fail!
> > 
> > I suspect that what you wanted to do, instead, is:
> > 
> > 	switch (fourcc) {
> > 	case V4L2_PIX_FMT_H264:
> > 	case V4L2_PIX_FMT_VP8:
> > 		break;
> > 	default:
> > 		return -EINVAL;
> >   
> 
> The original idea here is that vp8 and h264 are added in later patches.
> If get this patch without later patches, it should return -EINVAL.

I noticed your idea, but next time, don't add dead code like that.
Reviewers check patch by patch at the order they're present at the
patch series.

So, don't add something broken by purpose, assuming that it would
be fixed later.

> 
> 
> > Btw, this patch series has also several issues that were pointed by
> > checkpatch. Please *always* run checkpatch when submitting your work.
> > 
> > You should take a look at the Kernel documentation about how to
> > submit patches, at:
> > 	https://mchehab.fedorapeople.org/kernel_docs/process/index.html
> > 
> > PS.: this time, I fixed the checkpatch issues for you. So, let me know
> > if the patch below is OK, and I'll merge it at media upstream,
> > assuming that the other patches in this series are ok.
> >   
> 
> I did run checkpatch, but I don't know why these issues missed.
> probably I run checkpatch for all files not for patches.
> I will take a look at the documentation and keep this in mind for future
> upstream.
> Appreciated for your help.

Checkpatch should be run patch by patch, as we expect that all patches
will follow the coding style and will compile fine, without introducing
warnings.

I do compile the Kernel for every single patch I merge.

Regards,
Mauro

^ permalink raw reply

* [PATCH] asm-generic: Drop getrlimit and setrlimit syscalls from default list
From: James Hogan @ 2016-10-24  9:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477138444-14993-1-git-send-email-ynorov@caviumnetworks.com>

On Sat, Oct 22, 2016 at 03:14:04PM +0300, Yury Norov wrote:
> The newer prlimit64 syscall provides all the functionality provided by
> the getrlimit and setrlimit syscalls and adds the pid of target process,
> so future architectures won't need to include getrlimit and setrlimit.
> 
> Therefore drop getrlimit and setrlimit syscalls from the generic syscall
> list unless __ARCH_WANT_SET_GET_RLIMIT is defined by the architecture's
> unistd.h prior to including asm-generic/unistd.h, and adjust all
> architectures using the generic syscall list to define it so that no
> in-tree architectures are affected.
> 
> Cc: Vineet Gupta <vgupta@synopsys.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Salter <msalter@redhat.com>
> Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Richard Kuo <rkuo@codeaurora.org>
> Cc: James Hogan <james.hogan@imgtec.com>
> Cc: Ley Foon Tan <lftan@altera.com>
> Cc: Jonas Bonn <jonas@southpole.se>
> Cc: Chen Liqin <liqin.linux@gmail.com>
> Cc: Lennox Wu <lennox.wu@gmail.com>
> Cc: Chris Metcalf <cmetcalf@mellanox.com>
> Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Pinski <Andrew.Pinski@cavium.com>
> Cc: linux-snps-arc at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-c6x-dev at linux-c6x.org
> Cc: uclinux-h8-devel at lists.sourceforge.jp
> Cc: linux-hexagon at vger.kernel.org
> Cc: linux-metag at vger.kernel.org
> Cc: nios2-dev at lists.rocketboards.org
> Cc: linux-arch at vger.kernel.or
> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> 
> ---
>  arch/arc/include/uapi/asm/unistd.h       | 1 +
>  arch/arm64/include/uapi/asm/unistd.h     | 1 +
>  arch/c6x/include/uapi/asm/unistd.h       | 1 +
>  arch/h8300/include/uapi/asm/unistd.h     | 1 +
>  arch/hexagon/include/uapi/asm/unistd.h   | 1 +
>  arch/metag/include/uapi/asm/unistd.h     | 1 +

Acked-by: James Hogan <james.hogan@imgtec.com> [metag]

Cheers
James

>  arch/nios2/include/uapi/asm/unistd.h     | 1 +
>  arch/openrisc/include/uapi/asm/unistd.h  | 1 +
>  arch/score/include/uapi/asm/unistd.h     | 1 +
>  arch/tile/include/uapi/asm/unistd.h      | 1 +
>  arch/unicore32/include/uapi/asm/unistd.h | 1 +
>  include/uapi/asm-generic/unistd.h        | 5 +++++
>  12 files changed, 16 insertions(+)
> 
> diff --git a/arch/arc/include/uapi/asm/unistd.h b/arch/arc/include/uapi/asm/unistd.h
> index 41fa2ec..928546d 100644
> --- a/arch/arc/include/uapi/asm/unistd.h
> +++ b/arch/arc/include/uapi/asm/unistd.h
> @@ -16,6 +16,7 @@
>  #define _UAPI_ASM_ARC_UNISTD_H
>  
>  #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>  #define __ARCH_WANT_SYS_EXECVE
>  #define __ARCH_WANT_SYS_CLONE
>  #define __ARCH_WANT_SYS_VFORK
> diff --git a/arch/arm64/include/uapi/asm/unistd.h b/arch/arm64/include/uapi/asm/unistd.h
> index 043d17a..48355a6 100644
> --- a/arch/arm64/include/uapi/asm/unistd.h
> +++ b/arch/arm64/include/uapi/asm/unistd.h
> @@ -15,5 +15,6 @@
>   */
>  
>  #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>  
>  #include <asm-generic/unistd.h>
> diff --git a/arch/c6x/include/uapi/asm/unistd.h b/arch/c6x/include/uapi/asm/unistd.h
> index 12d73d9..f676231 100644
> --- a/arch/c6x/include/uapi/asm/unistd.h
> +++ b/arch/c6x/include/uapi/asm/unistd.h
> @@ -15,6 +15,7 @@
>   */
>  
>  #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>  #define __ARCH_WANT_SYS_CLONE
>  
>  /* Use the standard ABI for syscalls. */
> diff --git a/arch/h8300/include/uapi/asm/unistd.h b/arch/h8300/include/uapi/asm/unistd.h
> index 7dd20ef..2f98394 100644
> --- a/arch/h8300/include/uapi/asm/unistd.h
> +++ b/arch/h8300/include/uapi/asm/unistd.h
> @@ -1,5 +1,6 @@
>  #define __ARCH_NOMMU
>  
>  #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>  
>  #include <asm-generic/unistd.h>
> diff --git a/arch/hexagon/include/uapi/asm/unistd.h b/arch/hexagon/include/uapi/asm/unistd.h
> index 2151760..52d585c 100644
> --- a/arch/hexagon/include/uapi/asm/unistd.h
> +++ b/arch/hexagon/include/uapi/asm/unistd.h
> @@ -28,6 +28,7 @@
>  
>  #define sys_mmap2 sys_mmap_pgoff
>  #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>  #define __ARCH_WANT_SYS_EXECVE
>  #define __ARCH_WANT_SYS_CLONE
>  #define __ARCH_WANT_SYS_VFORK
> diff --git a/arch/metag/include/uapi/asm/unistd.h b/arch/metag/include/uapi/asm/unistd.h
> index 459b6ec..16b5cb3 100644
> --- a/arch/metag/include/uapi/asm/unistd.h
> +++ b/arch/metag/include/uapi/asm/unistd.h
> @@ -8,6 +8,7 @@
>   */
>  
>  #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>  
>  /* Use the standard ABI for syscalls. */
>  #include <asm-generic/unistd.h>
> diff --git a/arch/nios2/include/uapi/asm/unistd.h b/arch/nios2/include/uapi/asm/unistd.h
> index 51a32c7..b0dda4d 100644
> --- a/arch/nios2/include/uapi/asm/unistd.h
> +++ b/arch/nios2/include/uapi/asm/unistd.h
> @@ -18,6 +18,7 @@
>   #define sys_mmap2 sys_mmap_pgoff
>  
>  #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>  
>  /* Use the standard ABI for syscalls */
>  #include <asm-generic/unistd.h>
> diff --git a/arch/openrisc/include/uapi/asm/unistd.h b/arch/openrisc/include/uapi/asm/unistd.h
> index 471905b..6812d81 100644
> --- a/arch/openrisc/include/uapi/asm/unistd.h
> +++ b/arch/openrisc/include/uapi/asm/unistd.h
> @@ -21,6 +21,7 @@
>  #define sys_mmap2 sys_mmap_pgoff
>  
>  #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>  #define __ARCH_WANT_SYS_FORK
>  #define __ARCH_WANT_SYS_CLONE
>  
> diff --git a/arch/score/include/uapi/asm/unistd.h b/arch/score/include/uapi/asm/unistd.h
> index d4008c3..7ad1bdc 100644
> --- a/arch/score/include/uapi/asm/unistd.h
> +++ b/arch/score/include/uapi/asm/unistd.h
> @@ -1,6 +1,7 @@
>  #define __ARCH_HAVE_MMU
>  
>  #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>  #define __ARCH_WANT_SYSCALL_NO_AT
>  #define __ARCH_WANT_SYSCALL_NO_FLAGS
>  #define __ARCH_WANT_SYSCALL_OFF_T
> diff --git a/arch/tile/include/uapi/asm/unistd.h b/arch/tile/include/uapi/asm/unistd.h
> index 24e9187..cf0505f 100644
> --- a/arch/tile/include/uapi/asm/unistd.h
> +++ b/arch/tile/include/uapi/asm/unistd.h
> @@ -13,6 +13,7 @@
>   */
>  
>  #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>  #if !defined(__LP64__) || defined(__SYSCALL_COMPAT)
>  /* Use the flavor of this syscall that matches the 32-bit API better. */
>  #define __ARCH_WANT_SYNC_FILE_RANGE2
> diff --git a/arch/unicore32/include/uapi/asm/unistd.h b/arch/unicore32/include/uapi/asm/unistd.h
> index 1f63c47..ef25aec 100644
> --- a/arch/unicore32/include/uapi/asm/unistd.h
> +++ b/arch/unicore32/include/uapi/asm/unistd.h
> @@ -11,6 +11,7 @@
>   */
>  
>  #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>  
>  /* Use the standard ABI for syscalls. */
>  #include <asm-generic/unistd.h>
> diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
> index 9b1462e..bbaeac0 100644
> --- a/include/uapi/asm-generic/unistd.h
> +++ b/include/uapi/asm-generic/unistd.h
> @@ -465,10 +465,15 @@ __SYSCALL(__NR_uname, sys_newuname)
>  __SYSCALL(__NR_sethostname, sys_sethostname)
>  #define __NR_setdomainname 162
>  __SYSCALL(__NR_setdomainname, sys_setdomainname)
> +
> +#ifdef __ARCH_WANT_SET_GET_RLIMIT
> +/* getrlimit and setrlimit are superseded with prlimit64 */
>  #define __NR_getrlimit 163
>  __SC_COMP(__NR_getrlimit, sys_getrlimit, compat_sys_getrlimit)
>  #define __NR_setrlimit 164
>  __SC_COMP(__NR_setrlimit, sys_setrlimit, compat_sys_setrlimit)
> +#endif
> +
>  #define __NR_getrusage 165
>  __SC_COMP(__NR_getrusage, sys_getrusage, compat_sys_getrusage)
>  #define __NR_umask 166
> -- 
> 2.7.4
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/43e985fd/attachment-0001.sig>

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox