* [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 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 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
* 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 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
* [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 = <ðernet_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 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>;
};
-ðernet0 {
+&mac {
status = "okay";
- pinctrl-0 = <ðernet0_mii>;
+ pinctrl-0 = <ðernet_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 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/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 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 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 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 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 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
* 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] 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
* [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 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 4/4] serial: 8250_uniphier: avoid locking for FCR register write
From: Masahiro Yamada @ 2016-10-24 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477296030-7517-1-git-send-email-yamada.masahiro@socionext.com>
The hardware book says, the FCR is combined with a register called
CHAR (it will trigger interrupt when a specific character is
received). At first, I used lock/read/modify/write/unlock dance for
the FCR to not affect the upper bits, but the CHAR is actually never
used. It should not hurt to always clear the CHAR and to handle the
FCR as a normal case. It can save the costly locking.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Denys Vlasenko <dvlasenk@redhat.com>
---
drivers/tty/serial/8250/8250_uniphier.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_uniphier.c b/drivers/tty/serial/8250/8250_uniphier.c
index 92e7bb7..746680e 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -101,7 +101,7 @@ static unsigned int uniphier_serial_in(struct uart_port *p, int offset)
static void uniphier_serial_out(struct uart_port *p, int offset, int value)
{
unsigned int valshift = 0;
- bool normal = false;
+ bool normal = true;
switch (offset) {
case UART_FCR:
@@ -114,9 +114,9 @@ static void uniphier_serial_out(struct uart_port *p, int offset, int value)
/* fall through */
case UART_MCR:
offset = UNIPHIER_UART_LCR_MCR;
+ normal = false;
break;
default:
- normal = true;
offset <<= UNIPHIER_UART_REGSHIFT;
break;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] serial: 8250_uniphier: hardcode regshift to avoid unneeded memory read
From: Masahiro Yamada @ 2016-10-24 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477296030-7517-1-git-send-email-yamada.masahiro@socionext.com>
For this driver, uart_port::regshift is always 2. Hardcode the
shift value instead of reading ->regshift to get an already known
value. (pointed out by Denys Vlasenko)
Furthermore, I am using register macros that are already shifted,
which will save code a bit.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/tty/serial/8250/8250_uniphier.c | 42 +++++++++++++++++++--------------
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_uniphier.c b/drivers/tty/serial/8250/8250_uniphier.c
index 417d9e7..92e7bb7 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -24,10 +24,22 @@
/* Most (but not all) of UniPhier UART devices have 64-depth FIFO. */
#define UNIPHIER_UART_DEFAULT_FIFO_SIZE 64
-#define UNIPHIER_UART_CHAR_FCR 3 /* Character / FIFO Control Register */
-#define UNIPHIER_UART_LCR_MCR 4 /* Line/Modem Control Register */
-#define UNIPHIER_UART_LCR_SHIFT 8
-#define UNIPHIER_UART_DLR 9 /* Divisor Latch Register */
+/*
+ * This hardware is similar to 8250, but its register map is a bit different:
+ * - MMIO32 (regshift = 2)
+ * - FCR is not at 2, but 3
+ * - LCR and MCR are not at 3 and 4, they share 4
+ * - Divisor latch at 9, no divisor latch access bit
+ */
+
+#define UNIPHIER_UART_REGSHIFT 2
+
+/* bit[15:8] = CHAR (not used), bit[7:0] = FCR */
+#define UNIPHIER_UART_CHAR_FCR (3 << (UNIPHIER_UART_REGSHIFT))
+/* bit[15:8] = LCR, bit[7:0] = MCR */
+#define UNIPHIER_UART_LCR_MCR (4 << (UNIPHIER_UART_REGSHIFT))
+/* Divisor Latch Register */
+#define UNIPHIER_UART_DLR (9 << (UNIPHIER_UART_REGSHIFT))
struct uniphier8250_priv {
int line;
@@ -44,7 +56,7 @@ static int __init uniphier_early_console_setup(struct earlycon_device *device,
/* This hardware always expects MMIO32 register interface. */
device->port.iotype = UPIO_MEM32;
- device->port.regshift = 2;
+ device->port.regshift = UNIPHIER_UART_REGSHIFT;
/*
* Do not touch the divisor register in early_serial8250_setup();
@@ -68,17 +80,16 @@ static unsigned int uniphier_serial_in(struct uart_port *p, int offset)
switch (offset) {
case UART_LCR:
- valshift = UNIPHIER_UART_LCR_SHIFT;
+ valshift = 8;
/* fall through */
case UART_MCR:
offset = UNIPHIER_UART_LCR_MCR;
break;
default:
+ offset <<= UNIPHIER_UART_REGSHIFT;
break;
}
- offset <<= p->regshift;
-
/*
* The return value must be masked with 0xff because LCR and MCR reside
* in the same register that must be accessed by 32-bit write/read.
@@ -97,7 +108,7 @@ static void uniphier_serial_out(struct uart_port *p, int offset, int value)
offset = UNIPHIER_UART_CHAR_FCR;
break;
case UART_LCR:
- valshift = UNIPHIER_UART_LCR_SHIFT;
+ valshift = 8;
/* Divisor latch access bit does not exist. */
value &= ~UART_LCR_DLAB;
/* fall through */
@@ -106,11 +117,10 @@ static void uniphier_serial_out(struct uart_port *p, int offset, int value)
break;
default:
normal = true;
+ offset <<= UNIPHIER_UART_REGSHIFT;
break;
}
- offset <<= p->regshift;
-
if (normal) {
writel(value, p->membase + offset);
} else {
@@ -139,16 +149,12 @@ static void uniphier_serial_out(struct uart_port *p, int offset, int value)
*/
static int uniphier_serial_dl_read(struct uart_8250_port *up)
{
- int offset = UNIPHIER_UART_DLR << up->port.regshift;
-
- return readl(up->port.membase + offset);
+ return readl(up->port.membase + UNIPHIER_UART_DLR);
}
static void uniphier_serial_dl_write(struct uart_8250_port *up, int value)
{
- int offset = UNIPHIER_UART_DLR << up->port.regshift;
-
- writel(value, up->port.membase + offset);
+ writel(value, up->port.membase + UNIPHIER_UART_DLR);
}
static int uniphier_of_serial_setup(struct device *dev, struct uart_port *port,
@@ -234,7 +240,7 @@ static int uniphier_uart_probe(struct platform_device *pdev)
up.port.type = PORT_16550A;
up.port.iotype = UPIO_MEM32;
- up.port.regshift = 2;
+ up.port.regshift = UNIPHIER_UART_REGSHIFT;
up.port.flags = UPF_FIXED_PORT | UPF_FIXED_TYPE;
up.capabilities = UART_CAP_FIFO;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] serial: 8250_uniphier: fix clearing divisor latch access bit
From: Masahiro Yamada @ 2016-10-24 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477296030-7517-1-git-send-email-yamada.masahiro@socionext.com>
At this point, 'value' is always a byte, then this code is clearing
bit 15, which is already clear. I meant to clear bit 7.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: Denys Vlasenko <dvlasenk@redhat.com>
---
drivers/tty/serial/8250/8250_uniphier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_uniphier.c b/drivers/tty/serial/8250/8250_uniphier.c
index a8babb0..417d9e7 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -99,7 +99,7 @@ static void uniphier_serial_out(struct uart_port *p, int offset, int value)
case UART_LCR:
valshift = UNIPHIER_UART_LCR_SHIFT;
/* Divisor latch access bit does not exist. */
- value &= ~(UART_LCR_DLAB << valshift);
+ value &= ~UART_LCR_DLAB;
/* fall through */
case UART_MCR:
offset = UNIPHIER_UART_LCR_MCR;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] serial: 8250_uniphier: fix more unterminated string
From: Masahiro Yamada @ 2016-10-24 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477296030-7517-1-git-send-email-yamada.masahiro@socionext.com>
From: Denys Vlasenko <dvlasenk@redhat.com>
Commit 1681d2116c96 ("serial: 8250_uniphier: add "\n" at the end of
error log") missed this.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
[masahiro: add commit log]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/tty/serial/8250/8250_uniphier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_uniphier.c b/drivers/tty/serial/8250/8250_uniphier.c
index b8d9c8c..a8babb0 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -199,7 +199,7 @@ static int uniphier_uart_probe(struct platform_device *pdev)
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!regs) {
- dev_err(dev, "failed to get memory resource");
+ dev_err(dev, "failed to get memory resource\n");
return -EINVAL;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 0/4] serial: 8250_uniphier: some fixes and optimization
From: Masahiro Yamada @ 2016-10-24 8:00 UTC (permalink / raw)
To: linux-arm-kernel
This series is mostly based on excellent observant comments
from Denys Vlasenko.
- Add '\n' to a printk message
- Fix a minor bug
- Memory access optimization
- Locking optimization
Denys Vlasenko (1):
serial: 8250_uniphier: fix more unterminated string
Masahiro Yamada (3):
serial: 8250_uniphier: fix clearing divisor latch access bit
serial: 8250_uniphier: hardcode regshift to avoid unneeded memory read
serial: 8250_uniphier: avoid locking for FCR register write
drivers/tty/serial/8250/8250_uniphier.c | 50 ++++++++++++++++++---------------
1 file changed, 28 insertions(+), 22 deletions(-)
--
1.9.1
^ permalink raw reply
* [BUG] LPC32xx gpio driver broken by commit 762c2e46 in 4.9-rc1
From: Masahiro Yamada @ 2016-10-24 7:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZiG8B4K2Hf0mEcuOcq45=Q4n1yD4TDVJgJ+T7K1PMKAg@mail.gmail.com>
Hi.
2016-10-24 9:46 GMT+09:00 Linus Walleij <linus.walleij@linaro.org>:
> On Tue, Oct 18, 2016 at 6:23 PM, Sylvain Lemieux
> <slemieux.tyco@gmail.com> wrote:
>
>> the current LPC32xx GPIO driver is broken by commit 762c2e46
>> (gpio: of: remove of_gpiochip_and_xlate() and struct gg_data).
>>
>> A call to "of_get_named_gpio" to retrieve the GPIO will
>> always return -EINVAL, except for the first GPIO bank.
>>
>> Prior to this commit, the driver was working properly
>> because of the side-effect of the match function called by
>> "gpiochip_find" inside "of_get_named_gpiod_flags" function.
> (...)
>> Is there any short-term solution that can be done with
>> the existing driver to keep the LPC32xx platform working
>> properly in the 4.9 mainline kernel?
>
> Masahiro, what do you think is the best course to proceed here?
> Can we
> - Restore the behaviour prior to the patches or
> - Fix up all users or
> - Do we have to revert these two patches?
>
> I would prefer not to revert, because I liked the cleanup a lot ...
>
Personally, I do not want to revert, either.
I guess, this discussion comes down to
"is it justified to register multiple chips
associated to a single DT node?"
I feel like, DT properties such as
"gpio-hog", "gpio-ranges" assume one gpio_chip for one node.
We can register multi gpio_chip if we like, but
it looks odd to parse the same DT properties over and over again
looping gpio_chips.
If we move forward to single gpio_chip solution,
please check my RFC
"gpio: of: fix GPIO drivers with multiple gpio_chip for a single node"
as a long-term (but not too long) solution.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v3 0/2] clk: imx: fix AV PLL rate setting
From: Shawn Guo @ 2016-10-24 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476267249.git.emil@limesaudio.com>
On Wed, Oct 12, 2016 at 12:31:39PM +0200, Emil Lundmark wrote:
> Emil Lundmark (2):
> clk: imx: fix integer overflow in AV PLL round rate
> clk: imx: improve precision of AV PLL to 1 Hz
For both,
Acked-by: Shawn Guo <shawnguo@kernel.org>
^ 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