* [PATCH 07/11] ARM: dts: r8a7745: add Ether support
From: Sergei Shtylyov @ 2016-10-28 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4121805.SRTmqJtRfv@wasted.cogentembedded.com>
Define the generic R8A7745 part of the Ether device node.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/r8a7745.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7745.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7745.dtsi
+++ renesas/arch/arm/boot/dts/r8a7745.dtsi
@@ -418,6 +418,18 @@
power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
status = "disabled";
};
+
+ ether: ethernet at ee700000 {
+ compatible = "renesas,ether-r8a7745";
+ reg = <0 0xee700000 0 0x400>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 813>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ phy-mode = "rmii";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
/* External root clock */
^ permalink raw reply
* [PATCH 08/12] ARM: dts: r8a7745: add IRQC support
From: Sergei Shtylyov @ 2016-10-28 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4121805.SRTmqJtRfv@wasted.cogentembedded.com>
Describe the IRQC interrupt controller in the R8A7745 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/r8a7745.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7745.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7745.dtsi
+++ renesas/arch/arm/boot/dts/r8a7745.dtsi
@@ -62,6 +62,25 @@
IRQ_TYPE_LEVEL_HIGH)>;
};
+ irqc: interrupt-controller at e61c0000 {
+ compatible = "renesas,irqc-r8a7745", "renesas,irqc";
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ reg = <0 0xe61c0000 0 0x200>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 407>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
^ permalink raw reply
* [PATCH 10/12] ARM: dts: sk-rzg1e: initial device tree
From: Sergei Shtylyov @ 2016-10-28 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4121805.SRTmqJtRfv@wasted.cogentembedded.com>
---
arch/arm/boot/dts/Makefile | 1
arch/arm/boot/dts/r8a7745-sk-rzg1e.dts | 39 +++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
Index: renesas/arch/arm/boot/dts/Makefile
===================================================================
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -678,6 +678,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
r8a7743-sk-rzg1m.dtb \
+ r8a7745-sk-rzg1e.dtb \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
Index: renesas/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
@@ -0,0 +1,39 @@
+/*
+ * Device Tree Source for the SK-RZG1E board
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7745.dtsi"
+
+/ {
+ model = "SK-RZG1E";
+ compatible = "renesas,sk-rzg1e", "renesas,r8a7745";
+
+ aliases {
+ serial0 = &scif2;
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory at 40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x40000000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <20000000>;
+};
+
+&scif2 {
+ status = "okay";
+};
^ permalink raw reply
* [PATCH 10/12] ARM: dts: sk-rzg1e: initial device tree
From: Sergei Shtylyov @ 2016-10-28 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20818256.cBLNrMkA9r@wasted.cogentembedded.com>
On 10/29/2016 01:25 AM, Sergei Shtylyov wrote:
> ---
Oops, no description! :-/
I'll repost.
MBR, Sergei
^ permalink raw reply
* [PATCH 10/12] ARM: dts: sk-rzg1e: initial device tree
From: Sergei Shtylyov @ 2016-10-28 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4121805.SRTmqJtRfv@wasted.cogentembedded.com>
Add the initial device tree for the R8A7745 SoC based SK-RZG1E board.
The board has 1 debug serial port (SCIF2); include support for it,
so that the serial console can work.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/Makefile | 1
arch/arm/boot/dts/r8a7745-sk-rzg1e.dts | 39 +++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
Index: renesas/arch/arm/boot/dts/Makefile
===================================================================
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -678,6 +678,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
r8a7743-sk-rzg1m.dtb \
+ r8a7745-sk-rzg1e.dtb \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
Index: renesas/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
@@ -0,0 +1,39 @@
+/*
+ * Device Tree Source for the SK-RZG1E board
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7745.dtsi"
+
+/ {
+ model = "SK-RZG1E";
+ compatible = "renesas,sk-rzg1e", "renesas,r8a7745";
+
+ aliases {
+ serial0 = &scif2;
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory at 40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x40000000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <20000000>;
+};
+
+&scif2 {
+ status = "okay";
+};
^ permalink raw reply
* [PATCH 11/12] ARM: dts: sk-rzg1e: add Ether support
From: Sergei Shtylyov @ 2016-10-28 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4121805.SRTmqJtRfv@wasted.cogentembedded.com>
Define the SK-RZG1E board dependent part of the Ether device node.
Enable DHCP and NFS root for the kernel booting.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/r8a7745-sk-rzg1e.dts | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
Index: renesas/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
+++ renesas/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
@@ -20,7 +20,7 @@
};
chosen {
- bootargs = "ignore_loglevel";
+ bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
stdout-path = "serial0:115200n8";
};
@@ -37,3 +37,16 @@
&scif2 {
status = "okay";
};
+
+ðer {
+ phy-handle = <&phy1>;
+ renesas,ether-link-active-low;
+ status = "okay";
+
+ phy1: ethernet-phy at 1 {
+ reg = <1>;
+ interrupt-parent = <&irqc>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ micrel,led-mode = <1>;
+ };
+};
^ permalink raw reply
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-10-28 23:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2003579366.391192.0cc5acd0-af27-4ef7-892f-3c2dd86176ba.open-xchange@email.1und1.de>
On Sat, 2016-10-15 at 18:16 +0200, Stefan Wahren wrote:
> > J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Oktober 2016
> > um 11:41
> > geschrieben:
> >
> >
> >
> >
> > Hi Stefan,
> >
> > Am 15. Oktober 2016 10:59:41 MESZ, schrieb Stefan Wahren
> > <stefan.wahren@i2se.com>:
> > > Hi J?rg,
> > >
> > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Oktober
> > > > 2016 um
> > >
> > > 10:46
> > > > geschrieben:
> > > >
> > > >
> > > > Thanks!
> > > >
> > > >
> > > > For the record:
> > > >
> > > > Note, this is the result for the wireless interface.
> > > >
> > > > I got one of my custom boards running the legacy Linux Kernel
> > > > 2.6.35
> > > > officially supported from Freescale (NXP) and the bcmdhd driver
> > > > from
> > > > the Wiced project, where I get >20Mbps TCP throughput. The
> > > > firmware
> > > > version reported is:
> > > >
> > > > # wl ver
> > > > 5.90 RC115.2
> > > > wl0: Apr 24 2014 14:08:41 version 5.90.195.89.24 FWID 01-
> > > > bc2d0891
> > > >
> > > >
> > > > I got it also running with the Linux Kernel 4.1.15 from
> > > > Freescale
> > >
> > > [2],
> > > > which is not officially supported for the i.MX28 target, with
> > > > the
> > > > latest bcmdhd version where I get <7Mbps TCP throughput (which
> > > > is
> > >
> > > much
> > > > the same I get with the brcmfmac driver). The firmware version
> > >
> > > reported
> > > > is:
> > > >
> > > > # wl ver
> > > > 1.107 RC5.0
> > > > wl0: Aug??8 2016 02:17:48 version 5.90.232 FWID 01-0
> > > >
> > > > So, probably something is missing in the newer Kernel version,
> > > > which
> > >
> > > is
> > > > present in the legacy Kernel 2.6.35.
> > > >
> > > > [1]
> > >
> > > http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?
> > > h=
> > > > imx_2.6.35_1.1.0
> > > > [2]
> > >
> > > http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?
> > > h=
> > > > imx_4.1.15_1.0.0_ga
> > >
> > > during implementation of DDR mode for the mmc driver [1] i
> > > noticed a
> > > performance
> > > gap between the vendor kernel and mainline by a factor of 2. I
> > > expect
> > > that your
> > > wireless interface is connected via SDIO.
> >
> > Yes, it is. I had the suspicion that the MMC or the DMA driver is
> > the
> > bootleneck, too.
> >
> > >
> > > [1] -
> > > http://linux-arm-kernel.infradead.narkive.com/GNkqjvo8/patch-rfc-
> > > 0-3-mmc-mxs-mmc-implement-ddr-support
> >
> > Looks like the patches might help.
>
> Unfortunately not, the performance gain is smaller than expected.
>
> > Have you tried SDIO wifi so far?
>
> No.
You mentioned [1] an optimization in the Freescale vendor Linux kernel
[2]. I would really like to see this optimization in the mainline
kernel.
Did you ever tried to port this code from Freescale to mainline?
Is it even possible, as the mainline driver uses the DMA engine?
[1] http://linux-arm-kernel.infradead.narkive.com/GNkqjvo8/patch-rfc-0-
3-mmc-mxs-mmc-implement-ddr-support#post8
[2] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/
?h=imx_2.6.35_maintain&id=b09358887fb4b67f6d497fac8cc48475c8bd292d
Best regards,
J?rg Krause
^ permalink raw reply
* [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Stephen Boyd @ 2016-10-28 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028125112.xfyrx7l7m64z6cu6@atomide.com>
On 10/28, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [161028 00:43]:
> > On 28/10/16 03:50, Stephen Boyd wrote:
> > > I suppose a PRCM is
> > > like an MFD that has clocks and resets under it? On other
> > > platforms we've combined that all into one node and just had
> > > #clock-cells and #reset-cells in that node. Is there any reason
> > > we can't do that here?
> >
> > For OMAPs, there are typically multiple instances of the PRCM around; OMAP4
> > for example has:
> >
> > cm1 @ 0x4a004000 (clocks + clockdomains)
> > cm2 @ 0x4a008000 (clocks + clockdomains)
> > prm @ 0x4a306000 (few clocks + resets + power state handling)
> > scrm @ 0x4a30a000 (few external clocks + plenty of misc stuff)
> >
> > These instances are also under different power/voltage domains which means
> > their PM behavior is different.
> >
> > The idea behind having a clockdomain as a provider was mostly to have the
> > topology visible : prcm-instance -> clockdomain -> clocks
>
> Yeah that's needed to get the interconnect hierarchy right for
> genpd :)
>
> > ... but basically I think it would be possible to drop the clockdomain
> > representation and just mark the prcm-instance as a clock provider. Tony,
> > any thoughts on that?
>
> No let's not drop the clockdomains as those will be needed when we
> move things into proper hierarchy within the interconnect instances.
> This will then help with getting things right with genpd.
>
> In the long run we just want to specify clockdomain and the offset of
> the clock instance within the clockdomain in the dts files.
>
Sorry, I have very little idea how OMAP hardware works. Do you
mean that you will have different nodes for each clockdomain so
that genpd can map 1:1 to the node in dts? But in hardware
there's a prcm that allows us to control many clock domains
through register read/writes? How is the interconnect involved?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCHv4 00/15] clk: ti: add support for hwmod clocks
From: Stephen Boyd @ 2016-10-28 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2cfa10a9-9ea0-23e4-30de-9aece13e47e3@ti.com>
On 10/28, Tero Kristo wrote:
> Eventually that should happen. However, we have plenty of legacy
> code still in place which depend on clk_get functionality within
> kernel. The major contributing factor is the hwmod codebase, for
> which we have plans to:
>
> - get this clock driver merged
> - implement a new interconnect driver for OMAP family SoCs
> - interconnect driver will use DT handles for fetching clocks,
> rather than clock aliases
> - reset handling will be implemented as part of the interconnect
> driver somehow (no prototype / clear plans for that as of yet)
> - all the hwmod stuff can be dropped
>
> The clock alias handling is still needed as a transition phase until
> all the above is done, then we can start dropping them. Basically
> anything that is using omap_hwmod depends on the clock aliases right
> now.
Ok, sounds good. Thanks.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Tony Lindgren @ 2016-10-28 23:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028233617.GP16026@codeaurora.org>
* Stephen Boyd <sboyd@codeaurora.org> [161028 16:37]:
> On 10/28, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo@ti.com> [161028 00:43]:
> > > On 28/10/16 03:50, Stephen Boyd wrote:
> > > > I suppose a PRCM is
> > > > like an MFD that has clocks and resets under it? On other
> > > > platforms we've combined that all into one node and just had
> > > > #clock-cells and #reset-cells in that node. Is there any reason
> > > > we can't do that here?
> > >
> > > For OMAPs, there are typically multiple instances of the PRCM around; OMAP4
> > > for example has:
> > >
> > > cm1 @ 0x4a004000 (clocks + clockdomains)
> > > cm2 @ 0x4a008000 (clocks + clockdomains)
> > > prm @ 0x4a306000 (few clocks + resets + power state handling)
> > > scrm @ 0x4a30a000 (few external clocks + plenty of misc stuff)
> > >
> > > These instances are also under different power/voltage domains which means
> > > their PM behavior is different.
> > >
> > > The idea behind having a clockdomain as a provider was mostly to have the
> > > topology visible : prcm-instance -> clockdomain -> clocks
> >
> > Yeah that's needed to get the interconnect hierarchy right for
> > genpd :)
> >
> > > ... but basically I think it would be possible to drop the clockdomain
> > > representation and just mark the prcm-instance as a clock provider. Tony,
> > > any thoughts on that?
> >
> > No let's not drop the clockdomains as those will be needed when we
> > move things into proper hierarchy within the interconnect instances.
> > This will then help with getting things right with genpd.
> >
> > In the long run we just want to specify clockdomain and the offset of
> > the clock instance within the clockdomain in the dts files.
> >
>
> Sorry, I have very little idea how OMAP hardware works. Do you
> mean that you will have different nodes for each clockdomain so
> that genpd can map 1:1 to the node in dts? But in hardware
> there's a prcm that allows us to control many clock domains
> through register read/writes? How is the interconnect involved?
There are multiple clockdomains, at least one for each interconnect
instance. Once a clockdomain is idle, the related interconnect can
idle too. So yeah genpd pretty much maps 1:1 with the clockdomains.
There's more info in for example omap4 TRM section "3.4.1 Device
Power-Management Layout" that shows the voltage/power/clock domains.
The interconnect instances are mostly named there too looking at
the L4/L3 naming.
Regards,
Tony
^ permalink raw reply
* [PATCH 0/3] Remove clocks dependency from SCM driver
From: Sarangdhar Joshi @ 2016-10-29 0:08 UTC (permalink / raw)
To: linux-arm-kernel
On earlier chiptsets (APQ8064, MSM8660, MSM8690, MSM8916,
APQ8084, MSM8974) crypto operations of TZ were depends on crypto
clocks controlled by users/clients. However on MSM8996 crypto clocks
control is handled internally in TZ itself. The current series of
patches handle this clock dependency in SCM driver.
Sarangdhar Joshi (3):
dt-bindings: firmware: scm: Add MSM8996 DT bindings
firmware: qcom: scm: Remove core, iface and bus clocks dependency
firmware: qcom: scm: Return PTR_ERR when devm_clk_get fails
.../devicetree/bindings/firmware/qcom,scm.txt | 2 +
drivers/firmware/qcom_scm.c | 65 +++++++++++++++-------
2 files changed, 48 insertions(+), 19 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 1/3] dt-bindings: firmware: scm: Add MSM8996 DT bindings
From: Sarangdhar Joshi @ 2016-10-29 0:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477699729-18451-1-git-send-email-spjoshi@codeaurora.org>
Add SCM DT bindings for Qualcomm's MSM8996 platform.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
Documentation/devicetree/bindings/firmware/qcom,scm.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index 3b4436e..20f26fb 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -10,8 +10,10 @@ Required properties:
* "qcom,scm-apq8064" for APQ8064 platforms
* "qcom,scm-msm8660" for MSM8660 platforms
* "qcom,scm-msm8690" for MSM8690 platforms
+ * "qcom,scm-msm8996" for MSM8996 platforms
* "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
- clocks: One to three clocks may be required based on compatible.
+ * No clock required for "qcom,scm-msm8996"
* Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and "qcom,scm-msm8960"
* Core, iface, and bus clocks required for "qcom,scm"
- clock-names: Must contain "core" for the core clock, "iface" for the interface
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH] fpga zynq: Check the bitstream for validity
From: Moritz Fischer @ 2016-10-29 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028220546.GA19693@obsidianresearch.com>
Jason,
On Fri, Oct 28, 2016 at 04:05:46PM -0600, Jason Gunthorpe wrote:
> On Fri, Oct 28, 2016 at 02:00:15PM -0700, Moritz Fischer wrote:
>
> > > What did you do to get a working bitfile? Are you using one of the
> > > Vivado automatic flows that 'handles' this for you? I am not.
> >
> > https://github.com/EttusResearch/fpgadev/blob/master/usrp3/tools/scripts/viv_utils.tcl#L165
>
> Hm 404
Whooopsie ... that was the internal link. Try that one:
https://github.com/EttusResearch/fpga/blob/master/usrp3/tools/scripts/viv_utils.tcl#L165
It's not a single command but rather a sequence of steps we take to
create an image that works (using write_cfgmem instead of write_binfile)
>
> > Is what our build process does (we set the byte_swap_bin parameter to
> > 1). You're right in that write_bitstream will give you a non-swapped
> > version.
>
> ?? byte_swap_bin is not documented in UG835
>
> > If we reevaluate now that we wanna support swapping we should do this at
> > a framework level. Maybe a preprocess callback or a FPGA_MGR_SWAP flag.
> > I'll need to think about this :-)
>
> I'm perfectly fine with the driver only working with a single canonical
> bitfile format. That seems completly reasonable, and I prefer an
> efficient programming sequence for performance.
>
> Further, eventually this framework is going to have to be fixed to be
> able to DMA out of the page cache and in that world there is no
> sensible option to process the data before sending it on to the
> hardware.
>
> > > So from my perspective, this driver is incompatible with the output of
> > > the Xilinx tools. I don't really care, we always post-process the
> > > output of write_bitfile, and I am happy to provide a canonized
> > > bitstream, but the driver needs to do more to help people get this
> > > right.
> >
> > Ok, so I'm fine with adding the checks and a warning if you don't find
> > the sync word. We could add documentation describing which format we
> > expect.
>
> Maybe you could send a patch to update the comments for the driver, or
> add a documentation file how to produce an acceptable format using
> Xilinx tools..
Yeah will do. I don't know if the generation flow outlined above is perfect,
we just pad our images and I haven't run into issues so far.
> So, the question still remains, should the driver require the header
> be stripped (eg the sync word is the first 4 bytes), or should it
> search the first bit for an aligned sync word?
So currently we don't require it to be stripped, changing it so it does
require stripping would break people's setups that already use the
current implementation.
That being said, I don't like the idea of the driver having to search
either...
Michal, S?ren you guys have a preference / input?
> Either requirement is acceptable to the hardware. My patch does the
> former, I suspect you need the later?
For my usecases I could deal with either way, looking at backwards
compat the latter one would be preferential I supose ...
Cheers,
Moritz
^ permalink raw reply
* [PATCH 1/1] arm64: dts: msm8996: Add SCM DT node
From: Sarangdhar Joshi @ 2016-10-29 0:14 UTC (permalink / raw)
To: linux-arm-kernel
Add SCM DT node to enable SCM functionality on MSM8996.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 9e960c1..4927097 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -164,6 +164,12 @@
};
+ firmware {
+ scm {
+ compatible = "qcom,scm-msm8996";
+ };
+ };
+
tcsr_mutex: hwlock {
compatible = "qcom,tcsr-mutex";
syscon = <&tcsr_mutex_regs 0 0x1000>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v2 3/4] arm64: arch_timer: Work around Erratum Hisilicon-161601
From: Ding Tianhong @ 2016-10-29 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028160000.GB1076@arm.com>
On 2016/10/29 0:00, Will Deacon wrote:
> Hi Ding,
>
> On Thu, Oct 27, 2016 at 03:34:10PM +0800, Ding Tianhong wrote:
>> Erratum Hisilicon-161601 says that the ARM generic timer counter "has the
>> potential to contain an erroneous value when the timer value changes".
>> Accesses to TVAL (both read and write) are also affected due to the implicit counter
>> read. Accesses to CVAL are not affected.
>>
>> The workaround is to reread the system count registers until the value of the second
>> read is larger than the first one by less than 32, the system counter can be guaranteed
>> not to return wrong value twice by back-to-back read and the error value is always larger
>> than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL.
>>
>> The workaround is enabled if the hisilicon,erratum-161601 property is found in
>> the timer node in the device tree. This can be overridden with the
>> clocksource.arm_arch_timer.hisilicon-161601 boot parameter, which allows KVM
>> users to enable the workaround until a mechanism is implemented to
>> automatically communicate this information.
>>
>> Fix some description for fsl erratum a008585.
>>
>> v2: Significant rework based on feedback, including seperate the fsl erratum a008585
>> to another patch, update the erratum name and remove unwanted code.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>
> [...]
>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index 8a753fd..4aafb6a 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -312,8 +312,20 @@ config FSL_ERRATUM_A008585
>> help
>> This option enables a workaround for Freescale/NXP Erratum
>> A-008585 ("ARM generic timer may contain an erroneous
>> - value"). The workaround will only be active if the
>> + value"). The workaround will be active if the
>> fsl,erratum-a008585 property is found in the timer node.
>> + This can be overridden with the clocksource.arm_arch_timer.fsl-a008585
>> + boot parameter.
>> +
>> +config HISILICON_ERRATUM_161601
>> + bool "Workaround for Hisilicon Erratum 161601"
>> + default y
>> + depends on ARM_ARCH_TIMER && ARM64
>> + help
>> + This option enables a workaround for Hisilicon Erratum
>> + 161601. The workaround will be active if the hisilicon,erratum-161601
>> + property is found in the timer node. This can be overridden with
>> + the clocksource.arm_arch_timer.hisilicon-161601 boot parameter.
>
> I'm really not keen on having a kernel commandline parameter for this.
> It's not something we've done for other, similar errata (e.g. CNTFRQ
> reporting the wrong value) and I think it's a slippery slope to having
> more of these workarounds controlled at boot-time. If you have a board
> that is affected by this, it's always going to need the workaround. Why
> would you turn it off?
>
OK, miss it.
> Will
>
> .
>
^ permalink raw reply
* [PATCH v2 3/4] arm64: arch_timer: Work around Erratum Hisilicon-161601
From: Ding Tianhong @ 2016-10-29 2:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8267644f-c488-2d02-3dd0-c7d0ed23babf@arm.com>
On 2016/10/27 20:23, Marc Zyngier wrote:
> On 27/10/16 13:17, Ding Tianhong wrote:
>>
>>
>> On 2016/10/27 18:58, Marc Zyngier wrote:
>>> On 27/10/16 08:34, Ding Tianhong wrote:
>>>> Erratum Hisilicon-161601 says that the ARM generic timer counter "has the
>>>> potential to contain an erroneous value when the timer value changes".
>>>> Accesses to TVAL (both read and write) are also affected due to the implicit counter
>>>> read. Accesses to CVAL are not affected.
>>>>
>>>> The workaround is to reread the system count registers until the value of the second
>>>> read is larger than the first one by less than 32, the system counter can be guaranteed
>>>> not to return wrong value twice by back-to-back read and the error value is always larger
>>>> than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL.
>>>>
>>>> The workaround is enabled if the hisilicon,erratum-161601 property is found in
>>>> the timer node in the device tree. This can be overridden with the
>>>> clocksource.arm_arch_timer.hisilicon-161601 boot parameter, which allows KVM
>>>> users to enable the workaround until a mechanism is implemented to
>>>> automatically communicate this information.
>>>>
>>>> Fix some description for fsl erratum a008585.
>>>>
>>>> v2: Significant rework based on feedback, including seperate the fsl erratum a008585
>>>> to another patch, update the erratum name and remove unwanted code.
>>>>
>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>> ---
>>>> Documentation/arm64/silicon-errata.txt | 1 +
>>>> Documentation/kernel-parameters.txt | 9 ++++
>>>> arch/arm64/include/asm/arch_timer.h | 28 ++++++++++-
>>>> drivers/clocksource/Kconfig | 14 +++++-
>>>> drivers/clocksource/arm_arch_timer.c | 88 ++++++++++++++++++++++++++--------
>>>> 5 files changed, 118 insertions(+), 22 deletions(-)
>>>>
>>>> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
>>>> index 405da11..70c5d5e 100644
>>>> --- a/Documentation/arm64/silicon-errata.txt
>>>> +++ b/Documentation/arm64/silicon-errata.txt
>>>> @@ -63,3 +63,4 @@ stable kernels.
>>>> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
>>>> | | | | |
>>>> | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
>>>> +| Hisilicon | Hip05/Hip06/Hip07 | #161601 | HISILICON_ERRATUM_161601|
>>>
>>> I've already commented on the alignment. Please read my initial review.
>>>
>>
>> It sees misunderstood, fix it this time.
>>
>>>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>>>> index 6fa1d8a..735b4b6 100644
>>>> --- a/Documentation/kernel-parameters.txt
>>>> +++ b/Documentation/kernel-parameters.txt
>>>> @@ -707,6 +707,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>>>> erratum. If unspecified, the workaround is
>>>> enabled based on the device tree.
>>>>
>>>> + clocksource.arm_arch_timer.hisilicon-161601=
>>>> + [ARM64]
>>>> + Format: <bool>
>>>> + Enable/disable the workaround of Hisilicon
>>>> + erratum 161601. This can be useful for KVM
>>>> + guests, if the guest device tree doesn't show the
>>>> + erratum. If unspecified, the workaround is
>>>> + enabled based on the device tree.
>>>> +
>>>> clearcpuid=BITNUM [X86]
>>>> Disable CPUID feature X for the kernel. See
>>>> arch/x86/include/asm/cpufeatures.h for the valid bit
>>>> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
>>>> index 118719d8..49b3041 100644
>>>> --- a/arch/arm64/include/asm/arch_timer.h
>>>> +++ b/arch/arm64/include/asm/arch_timer.h
>>>> @@ -29,7 +29,7 @@
>>>>
>>>> #include <clocksource/arm_arch_timer.h>
>>>>
>>>> -#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
>>>> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
>>>> extern struct static_key_false arch_timer_read_ool_enabled;
>>>> #define needs_timer_erratum_workaround() \
>>>> static_branch_unlikely(&arch_timer_read_ool_enabled)
>>>> @@ -65,11 +65,35 @@ extern struct arch_timer_erratum_workaround *erratum_workaround;
>>>> _new; \
>>>> })
>>>>
>>>> +
>>>> +
>>>> +/*
>>>> + * The number of retries is an arbitrary value well beyond the highest number
>>>> + * of iterations the loop has been observed to take.
>>>> + * Verify whether the value of the second read is larger than the first by
>>>> + * less than 32 is the only way to confirm the value is correct, the system
>>>> + * counter can be guaranteed not to return wrong value twice by back-to-back read
>>>> + * and the error value is always larger than the correct one by 32.
>>>> + */
>>>> +#define __hisi_161601_read_reg(reg) ({ \
>>>> + u64 _old, _new; \
>>>> + int _retries = 200; \
>>>
>>> Please document how this value was found (either in the code or in the
>>> commit message).
>>
>> It really difficult to give the accurate standard, theoretically the error should not happened
>> twice together, so maybe 2 is enough here, I just give a arbitrary value.
>>
>>>
>>>> + \
>>>> + do { \
>>>> + _old = read_sysreg(reg); \
>>>> + _new = read_sysreg(reg); \
>>>> + _retries--; \
>>>> + } while (unlikely((_new - _old) >> 5) && _retries); \
>>>> + \
>>>> + WARN_ON_ONCE(!_retries); \
>>>> + _new; \
>>>> +})
>>>
>>> Same remark as in the previous patch.
>>>
>>
>> I think the sentence *Verify whether the value of the second read is larger than the first by
>> less than 32 is the only way to confirm the value is correct* could explain why should *(_new - _old) >> 5*.
>> it is the same as (_new - _old)/32, also mean the _new should never bigger than _old more than 32.
>
> This is not about the explanation of the erratum, but about the location
> of the #define, which can be made private to the .c file instead of
> being globally visible.
>
Ok, update it .
Thanks
Ding
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCH 1/2] PCI: iproc: Support DT property for ignoring aborts when probing
From: Rafał Miłecki @ 2016-10-29 6:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b58db80-c9ff-d4d6-0df1-d80d1c03bc45@broadcom.com>
On 28 October 2016 at 18:58, Ray Jui <ray.jui@broadcom.com> wrote:
> On 10/28/2016 8:31 AM, Rafa? Mi?ecki wrote:
>> On 20 April 2016 at 20:18, Ray Jui <ray.jui@broadcom.com> wrote:
>>> Hi Rafal/Florian/Arnd,
>>>
>>> After a couple days of email exchange with the ASIC team, I think I've
>>> figured out the behavior on all of the Broadcom SoCs that use this iProc
>>> PCIe controller.
>>>
>>> On NSP, Cygnus, and NS2:
>>> - There's an APB error enable register at offset 0xf40 from the iProc PCIe
>>> controller's base address. If one clears bit 0 (enabled by default after
>>> chip POR) of that register, one can stop this from being forwarded to "iProc
>>> host" as an APB error/external imprecise abort
>>> - I will submit a patch to the iProc PCIe driver to disable this error
>>> forwarding
>>>
>>> On NS:
>>> - Unfortunately, there's no such control register in NS. In other words, we
>>> cannot disable this error at the PCIe controller level
>>> - FSR code corresponds to external (bit[12] = '1'), read (bit[11] = '0'),
>>> imprecise abort (bits[10][3:0] = '1''0110'), i.e., external imprecise abort
>>> triggered by read access. Our ASIC team believes a read access to a
>>> non-exist APB register can also trigger an abort with the same FSR code.
>>> Note this is the tricky part, by registering an abort hook that skips this
>>> particular FSR, one has a chance of skipping other aborts triggered by
>>> accessing invalid APB registers. But given that this cannot be disabled for
>>> the PCIe controller NS, I'm not sure what approach we should take. Any
>>> thoughts?
>>
>> It's really late reply but I wanted to finally handle this problem.
>>
>> From Ray's e-mail it seems Northstar is the only platform requiring
>> this workaround. So we don't have to worry about arm64.
>
> Yes, Northstar is the only platform that requires this workaround. Even
> the arm32 platforms like NSP and Cygnus can disable unsupported request
> being forwarded as APB error. I've recently sent out a patch series to
> fix this for all other platforms, and sorry I should have included you
> in the email but I did not. I'll include you when revision 2 is sent out.
>
>>
>> We have two options then:
>> 1) Add workaround in arch/arm/mach-bcm/bcm_5301x.c
>> 2) Add workaround into built-in drivers/pci/host/pcie-iproc-fault.c
>
> How do you plan to implement pcie-iproc-fault.c? If it's similar to what
> you have now, then I think it fits more to bcm_5301x.c
Yes, I just wanted to have a simple file with 2 functions there: one
adding a hook and second being a callback.
--
Rafa?
^ permalink raw reply
* [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Andrew Lunn @ 2016-10-29 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477688219-3871-3-git-send-email-jon.mason@broadcom.com>
On Fri, Oct 28, 2016 at 04:56:55PM -0400, Jon Mason wrote:
> The BCM54810 PHY requires some semi-unique configuration, which results
> in some additional configuration in addition to the standard config.
> Also, some users of the BCM54810 require the PHY lanes to be swapped.
> Since there is no way to detect this, add a device tree query to see if
> it is applicable.
>
> Inspired-by: Vikas Soni <vsoni@broadcom.com>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> drivers/net/phy/Kconfig | 2 +-
> drivers/net/phy/broadcom.c | 58 +++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/brcmphy.h | 10 ++++++++
Hi Jon
The binding documentation is missing.
> + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap")) {
> + /* Lane Swap - Undocumented register...magic! */
> + ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
> + 0x11B);
> + if (ret < 0)
> + return ret;
> + }
> +
I wounder if this property could be made generic? What exactly are you
swapping? Rx and Tx lanes? Maybe we should add it to phy.txt?
Andrew
^ permalink raw reply
* [PATCH] video: ARM CLCD: fix Vexpress regression
From: Linus Walleij @ 2016-10-29 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476945992-5164-1-git-send-email-linus.walleij@linaro.org>
On Thu, Oct 20, 2016 at 8:46 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> The CLCD does not come up on Versatile Express as it does not
> (currently) have a syscon node for controlling the block apart
> from the CLCD itself. Make sure the .init() function can bail
> out without an error making it probe again.
>
> Reported-by: Amit Pundir <amit.pundir@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tomi can you please pick this up?
Yours,
Linus Walleij
^ permalink raw reply
* pinctrl: mediatek: build failure if CONFIG_IRQ_DOMAIN is not set
From: Linus Walleij @ 2016-10-29 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477675233.2167.11.camel@tiscali.nl>
On Fri, Oct 28, 2016 at 7:20 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
> 3) Would you like me to submit a proper (but lightly tested) patch or
> do you prefer to fix this yourself?
Please send a tested patch, I'll apply it.
Thanks for finding this!
Yours,
Linus Walleij
^ permalink raw reply
* [RFC][PATCH] arm64: Add support for CONFIG_DEBUG_VIRTUAL
From: Ard Biesheuvel @ 2016-10-29 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6a76edf2-3f80-fb18-4fc1-2e0b1f085d20@redhat.com>
On 28 October 2016 at 23:07, Laura Abbott <labbott@redhat.com> wrote:
>>>> diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
>>>> new file mode 100644
>>>> index 0000000..6c271e2
>>>> --- /dev/null
>>>> +++ b/arch/arm64/mm/physaddr.c
>>>> @@ -0,0 +1,17 @@
>>>> +#include <linux/mm.h>
>>>> +
>>>> +#include <asm/memory.h>
>>>> +
>>>> +unsigned long __virt_to_phys(unsigned long x)
>>>> +{
>>>> + phys_addr_t __x = (phys_addr_t)x;
>>>> +
>>>> + if (__x & BIT(VA_BITS - 1)) {
>>>> + /* The bit check ensures this is the right range */
>>>> + return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
>>>> + } else {
>>>> + VIRTUAL_BUG_ON(x < kimage_vaddr || x > (unsigned long)_end);
>>>
>>>
>>> IIUC, in (3) you were asking if the last check should be '>' or '>='?
>>>
>>> To match high_memory, I suspect the latter, as _end doesn't fall within
>>> the mapped virtual address space.
>>>
>>
>> I was actually concerned about if _end would be correct with KASLR.
>> Ard confirmed that it gets fixed up to be correct. I'll change the
>> check to check for >=.
>>
>
> While testing this, I found two places with __pa(_end) to get bounds,
> one in arm64 code and one in memblock code. x86 gets away with this
> because memblock is actually __pa_symbol and x86 does image placement
> different and can check against the maximum image size. I think
> including _end in __pa_symbol but excluding it from the generic
> __virt_to_phys makes sense. It's a bit nicer than doing _end - 1 +
> 1 everywhere.
>
Could we redefine __pa_symbol() under CONFIG_DEBUG_VIRTUAL to
something that checks (x >= kimage_vaddr + TEXT_OFFSET || x <=
(unsigned long)_end), i.e., reject linear virtual addresses? (Assuming
my understanding of the meaning of __pa_symbol() is correct)
^ permalink raw reply
* [PATCH v3 1/6] pinctrl: sunxi: Deal with configless pins
From: Linus Walleij @ 2016-10-29 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ae812275bfb0f0ded2a73b571bfcecffcd747126.1476971126.git-series.maxime.ripard@free-electrons.com>
On Thu, Oct 20, 2016 at 3:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Even though the our binding had the assumption that the allwinner,pull and
> allwinner,drive properties were optional, the code never took that into
> account.
>
> Fix that.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Low network throughput on i.MX28
From: Stefan Wahren @ 2016-10-29 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477696028.31471.3.camel@embedded.rocks>
> J?rg Krause <joerg.krause@embedded.rocks> hat am 29. Oktober 2016 um 01:07
> geschrieben:
>
>
> You mentioned [1] an optimization in the Freescale vendor Linux kernel
> [2]. I would really like to see this optimization in the mainline
> kernel.
>
> Did you ever tried to port this code from Freescale to mainline?
Yes, i tried once but i was frustrated soon because of the lot of required
changes and resulting issues.
>
> Is it even possible, as the mainline driver uses the DMA engine?
I think the more important part would be analyse why the Mainline driver is
slowlier. I mean to exactly identify the bottleneck.
I don't have enough time and equipment for this. I better concentrate on standby
support.
>
> [1] http://linux-arm-kernel.infradead.narkive.com/GNkqjvo8/patch-rfc-0-
> 3-mmc-mxs-mmc-implement-ddr-support#post8
> [2] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/
> ?h=imx_2.6.35_maintain&id=b09358887fb4b67f6d497fac8cc48475c8bd292d
>
> Best regards,
> J?rg Krause
^ permalink raw reply
* [PATCH v12 RESEND 0/4] generic TEE subsystem
From: Jens Wiklander @ 2016-10-29 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1e532aeb-4944-62e4-c8c4-1e23438b92cd@ti.com>
On Fri, Oct 28, 2016 at 10:43:24AM -0500, Andrew F. Davis wrote:
> On 10/28/2016 05:19 AM, Jens Wiklander wrote:
> > Hi,
> >
> > This patch set introduces a generic TEE subsystem. The TEE subsystem will
> > contain drivers for various TEE implementations. A TEE (Trusted Execution
> > Environment) is a trusted OS running in some secure environment, for
> > example, TrustZone on ARM CPUs, or a separate secure co-processor etc.
> >
> > Regarding use cases, TrustZone has traditionally been used for
> > offloading secure tasks to the secure world. Examples include:
> > - Secure key handling where the OS may or may not have direct access to key
> > material.
> > - E-commerce and payment technologies. Credentials, credit card numbers etc
> > could be stored in a more secure environment.
> > - Trusted User Interface (TUI) to ensure that no-one can snoop PIN-codes
> > etc.
> > - Secure boot to ensure that loaded binaries haven?t been tampered with.
> > It?s not strictly needed for secure boot, but you could enhance security
> > by leveraging a TEE during boot.
> > - Digital Rights Management (DRM), the studios provides content with
> > different resolution depending on the security of the device. Higher
> > security means higher resolution.
> >
> > A TEE could also be used in existing and new technologies. For example IMA
> > (Integrity Measurement Architecture) which has been in the kernel for quite
> > a while. Today you can enhance security by using a TPM-chip to sign the IMA
> > measurement list. This is something that you also could do by leveraging a
> > TEE.
> >
> > Another example could be in 2-factor authentication which is becoming
> > increasingly more important. FIDO (https://fidoalliance.org) for example
> > are using public key cryptography in their 2-factor authentication standard
> > (U2F). With FIDO, a private and public key pair will be generated for every
> > site you visit and the private key should never leave the local device.
> > This is an example where you could use secure storage in a TEE for the
> > private key.
> >
> > Today you will find a quite a few different out of tree implementations of
> > TEE drivers which tends to fragment the TEE ecosystem and development. We
> > think it would be a good idea to have a generic TEE driver integrated in
> > the kernel which would serve as a base for several different TEE solutions,
> > no matter if they are on-chip like TrustZone or if they are on a separate
> > crypto co-processor.
> >
> > To develop this TEE subsystem we have been using the open source TEE called
> > OP-TEE (https://github.com/OP-TEE/optee_os) and therefore this would be the
> > first TEE solution supported by this new subsystem. OP-TEE is a
> > GlobalPlatform compliant TEE, however this TEE subsystem is not limited to
> > only GlobalPlatform TEEs, instead we have tried to design it so that it
> > should work with other TEE solutions also.
> >
>
> The above is my biggest concern with this whole subsystem, to me it
> still feels very OPTEE specific. As much as I would love to believe
> OPTEE will be the end-all TEE, I'm sure we soon will start to see wider
> use of vendor TEEs (like TI's own legacy Trustzone thing we are hoping
> to depreciate with OPTEE moving forward), possibly Google's Trusty TEE,
> and whatever Intel/AMD are cooking up for x86.
I'd rather say that it's slightly GlobalPlatform specific, but a bit
more flexible.
>
> As we all know when things are upstreamed we lose the ability to make
> radical changes easily, especially to full subsystems. What happens when
> this framework, built with only one existing TEE, built by the one
> existing TEE's devs, is not as flexible as we need when other TEEs start
> rolling out?
Initially the TEE subsystem was much more flexible and was criticized
for that.
>
> Do we see this as a chicken and egg situation, or is there any harm
> beyond the pains of supporting an out-of-tree driver for a while, to
> wait until we have at least one other TEE to add to this subsystem
> before merging?
This proposal is the bare minimum to have something useful. On top of
this there's more things we'd like to add, for example an in-kernel API
for accessing the TEE and secure buffer handling. The way we're dealing
with shared memory need to be improved to better support multiple guests
communicating with one TEE.
What we can do now with the subsystem now is somewhat limited by the
fact that we're trying to upstream it and want to do that it in
manageable increments.
Thanks,
Jens
>
> This may also help with the perceived lack of reviewers for this series.
>
> Thanks,
> Andrew
>
> > "tee: generic TEE subsystem" brings in the generic TEE subsystem which
> > helps when writing a driver for a specific TEE, for example, OP-TEE.
> >
> > "tee: add OP-TEE driver" is an OP-TEE driver which uses the subsystem to do
> > its work.
> >
> > This patch set has been prepared in cooperation with Javier Gonz?lez who
> > proposed "Generic TrustZone Driver in Linux Kernel" patches 28 Nov 2014,
> > https://lwn.net/Articles/623380/ . We've since then changed the scope to
> > TEE instead of TrustZone.
> >
> > We have discussed the design on tee-dev at lists.linaro.org (archive at
> > https://lists.linaro.org/pipermail/tee-dev/) with people from other
> > companies, including Valentin Manea <valentin.manea@huawei.com>,
> > Emmanuel MICHEL <emmanuel.michel@st.com>,
> > Jean-michel DELORME <jean-michel.delorme@st.com>,
> > and Joakim Bech <joakim.bech@linaro.org>. Our main concern has been to
> > agree on something that is generic enough to support many different
> > TEEs while still keeping the interface together.
> >
> > v12-resend:
> > * Rebased on v4.9-rc2
> >
> > v12:
> > * Rebased on v4.8-rc5
> > * Addressed review comments from Andrew F. Davis
> > * Removed Acked-by: Andreas Dannenberg <dannenberg@ti.com> as the
> > mail bounces
> > * Bugfix possible null dereference in error cleanup path of
> > optee_probe().
> > * Bugfix optee_from_msg_param() when calculating offset of memref
> > into a shared memory object
> >
> > v11:
> > * Rebased on v4.8-rc3
> > * Addressed review comments from Nishanth Menon
> > * Made the TEE framework available as a loadable module.
> > * Reviewed-by: Javier Gonz?lez <javier@javigon.com>
> > * Zeroes shared memory on allocation to avoid information leakage
> > * Links shared memory objects to context to avoid stealing of shared memory
> > object from an unrelated process
> > * Allow RPC interruption if supplicant is unavailable
> >
> > v10:
> > * Rebased on v4.7-rc1
> > * Addressed private review comments from Nishanth Menon
> > * Optee driver only accepts one supplicant process on the privileged device
> > * Optee driver avoids long delayed releases of shm objects
> > * Added more comments on functions and structs
> >
> > v9:
> > * Rebased on v4.6-rc1
> > * Acked-by: Andreas Dannenberg <dannenberg@ti.com>
> > * Addressed comments from Al Viro how file descriptors are passed to
> > user space
> > * Addressed comments from Randy Dunlap on documentation
> > * Changed license for include/uapi/linux/tee.h
> >
> > v8:
> > * Rebased on v4.5-rc3
> > * dt/bindings: add bindings for optee
> > Acked-by: Rob Herring <robh@kernel.org>
> > * Fixes build error for X86
> > * Fixes spell error in "dt/bindings: add bindings for optee"
> >
> > v7:
> > * Rebased on v4.5-rc2
> > * Moved the ARM SMC Calling Convention support into a separate patch
> > set, which is now merged
> >
> > v6:
> > * Rebased on v4.3-rc7
> > * Changed smccc interface to let the compiler marshal most of the
> > parameters
> > * Added ARCH64 capability for smccc interface
> > * Changed the PSCI firmware calls (both arm and arm64) to use the new
> > generic smccc interface instead instead of own assembly functions.
> > * Move optee DT bindings to below arm/firmware
> > * Defines method for OP-TEE driver to call secure world in DT, smc or hvc
> > * Exposes implementation id of a TEE driver in sysfs
> > to easily spawn corresponding tee-supplicant when device is ready
> > * Update OP-TEE Message Protocol to better cope with fragmented physical
> > memory
> > * Read time directly from OP-TEE driver instead of forwarding the RPC
> > request to tee-supplicant
> >
> > v5:
> > * Replaced kref reference counting for the device with a size_t instead as
> > the counter is always protected by a mutex
> >
> > v4:
> > * Rebased on 4.1
> > * Redesigned the synchronization around entry exit of normal SMC
> > * Replaced rwsem on the driver instance with kref and completion since
> > rwsem wasn't intended to be used in this way
> > * Expanded the TEE_IOCTL_PARAM_ATTR_TYPE_MASK to make room for
> > future additional parameter types
> > * Documents TEE subsystem and OP-TEE driver
> > * Replaced TEE_IOC_CMD with TEE_IOC_OPEN_SESSION, TEE_IOC_INVOKE,
> > TEE_IOC_CANCEL and TEE_IOC_CLOSE_SESSION
> > * DT bindings in a separate patch
> > * Assembly parts moved to arch/arm and arch/arm64 respectively, in a
> > separate patch
> > * Redefined/clarified the meaning of OPTEE_SMC_SHM_CACHED
> > * Removed CMA usage to limit the scope of the patch set
> >
> > v3:
> > * Rebased on 4.1-rc3 (dma_buf_export() API change)
> > * A couple of small sparse fixes
> > * Documents bindings for OP-TEE driver
> > * Updated MAINTAINERS
> >
> > v2:
> > * Replaced the stubbed OP-TEE driver with a real OP-TEE driver
> > * Removed most APIs not needed by OP-TEE in current state
> > * Update Documentation/ioctl/ioctl-number.txt with correct path to tee.h
> > * Rename tee_shm_pool_alloc_cma() to tee_shm_pool_alloc()
> > * Moved tee.h into include/uapi/linux/
> > * Redefined tee.h IOCTL macros to be directly based on _IOR and friends
> > * Removed version info on the API to user space, a data blob which
> > can contain an UUID is left for user space to be able to tell which
> > protocol to use in TEE_IOC_CMD
> > * Changed user space exposed structures to only have types with __ prefix
> > * Dropped THIS_MODULE from tee_fops
> > * Reworked how the driver is registered and ref counted:
> > - moved from using an embedded struct miscdevice to an embedded struct
> > device.
> > - uses an struct rw_semaphore as synchronization for driver detachment
> > - uses alloc/register pattern from TPM
> >
> > Thanks,
> > Jens
> >
> > Jens Wiklander (4):
> > dt/bindings: add bindings for optee
> > tee: generic TEE subsystem
> > tee: add OP-TEE driver
> > Documentation: tee subsystem and op-tee driver
> >
> > Documentation/00-INDEX | 2 +
> > .../bindings/arm/firmware/linaro,optee-tz.txt | 31 +
> > .../devicetree/bindings/vendor-prefixes.txt | 1 +
> > Documentation/ioctl/ioctl-number.txt | 1 +
> > Documentation/tee.txt | 118 +++
> > MAINTAINERS | 13 +
> > drivers/Kconfig | 2 +
> > drivers/Makefile | 1 +
> > drivers/tee/Kconfig | 18 +
> > drivers/tee/Makefile | 5 +
> > drivers/tee/optee/Kconfig | 7 +
> > drivers/tee/optee/Makefile | 5 +
> > drivers/tee/optee/call.c | 435 ++++++++++
> > drivers/tee/optee/core.c | 598 ++++++++++++++
> > drivers/tee/optee/optee_msg.h | 435 ++++++++++
> > drivers/tee/optee/optee_private.h | 185 +++++
> > drivers/tee/optee/optee_smc.h | 446 ++++++++++
> > drivers/tee/optee/rpc.c | 404 +++++++++
> > drivers/tee/optee/supp.c | 273 +++++++
> > drivers/tee/tee_core.c | 901 +++++++++++++++++++++
> > drivers/tee/tee_private.h | 129 +++
> > drivers/tee/tee_shm.c | 357 ++++++++
> > drivers/tee/tee_shm_pool.c | 158 ++++
> > include/linux/tee_drv.h | 278 +++++++
> > include/uapi/linux/tee.h | 403 +++++++++
> > 25 files changed, 5206 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> > create mode 100644 Documentation/tee.txt
> > create mode 100644 drivers/tee/Kconfig
> > create mode 100644 drivers/tee/Makefile
> > create mode 100644 drivers/tee/optee/Kconfig
> > create mode 100644 drivers/tee/optee/Makefile
> > create mode 100644 drivers/tee/optee/call.c
> > create mode 100644 drivers/tee/optee/core.c
> > create mode 100644 drivers/tee/optee/optee_msg.h
> > create mode 100644 drivers/tee/optee/optee_private.h
> > create mode 100644 drivers/tee/optee/optee_smc.h
> > create mode 100644 drivers/tee/optee/rpc.c
> > create mode 100644 drivers/tee/optee/supp.c
> > create mode 100644 drivers/tee/tee_core.c
> > create mode 100644 drivers/tee/tee_private.h
> > create mode 100644 drivers/tee/tee_shm.c
> > create mode 100644 drivers/tee/tee_shm_pool.c
> > create mode 100644 include/linux/tee_drv.h
> > create mode 100644 include/uapi/linux/tee.h
> >
^ permalink raw reply
* [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias
From: Ard Biesheuvel @ 2016-10-29 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476787939-21889-2-git-send-email-ard.biesheuvel@linaro.org>
On 18 October 2016 at 11:52, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> Wire up the generic support for exposing CPU feature bits via the
> modalias in /sys/device/system/cpu. This allows udev to automatically
> load modules for things like crypto algorithms that are implemented
> using optional instructions.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
> 2 files changed, 33 insertions(+)
>
Russell,
do you have any concerns regarding this patch? If not, I will drop it
into the patch system.
Herbert,
I will resend the followup patches in this series to linux-crypto@
once this prerequisite is in place
Thanks,
Ard.
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index b5d529fdffab..1a0c6a486a9c 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -21,6 +21,7 @@ config ARM
> select GENERIC_ALLOCATOR
> select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
> select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> + select GENERIC_CPU_AUTOPROBE
> select GENERIC_EARLY_IOREMAP
> select GENERIC_IDLE_POLL_SETUP
> select GENERIC_IRQ_PROBE
> diff --git a/arch/arm/include/asm/cpufeature.h b/arch/arm/include/asm/cpufeature.h
> new file mode 100644
> index 000000000000..19c3dddd901a
> --- /dev/null
> +++ b/arch/arm/include/asm/cpufeature.h
> @@ -0,0 +1,32 @@
> +/*
> + * Copyright (C) 2016 Linaro Ltd. <ard.biesheuvel@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __ASM_CPUFEATURE_H
> +#define __ASM_CPUFEATURE_H
> +
> +#include <asm/hwcap.h>
> +
> +/*
> + * Due to the fact that ELF_HWCAP is a 32-bit type on ARM, and given the number
> + * of optional CPU features it defines, ARM's CPU capability bits have been
> + * divided across separate elf_hwcap and elf_hwcap2 variables, each of which
> + * covers a subset of the available CPU features.
> + *
> + * Currently, only a few of those are suitable for automatic module loading
> + * (which is the primary use case of this facility) and those happen to be all
> + * covered by HWCAP2. So let's only expose those via the CPU modalias for now.
> + */
> +#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap2))
> +#define cpu_feature(x) ilog2(HWCAP2_ ## x)
> +
> +static inline bool cpu_have_feature(unsigned int num)
> +{
> + return elf_hwcap2 & (1UL << num);
> +}
> +
> +#endif
> --
> 2.7.4
>
^ 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