* [GIT PULL] ARM: OMAP2+: first set of hwmod data patches for v3.17
From: Paul Walmsley @ 2014-07-22 21:21 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tony
The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:
Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.17/omap-hwmod-a
for you to fetch changes up to c913c8a15a02e91c1f0302d68bebf66838a9689d:
ARM: DRA7: hwmod: Add data for RTC (2014-07-22 14:35:06 -0600)
- ----------------------------------------------------------------
OMAP hwmod data additions for v3.17. Most of these are DRA7xx-related,
although one patch adds DSS hwmods for AM43xx.
Basic build, boot, and PM test results are available here:
http://www.pwsan.com/omap/testlogs/hwmod-a-v3.17/20140722143514/
- ----------------------------------------------------------------
Kishon Vijay Abraham I (2):
arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy
arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
Lokesh Vutla (1):
ARM: DRA7: hwmod: Add data for RTC
Mugunthan V N (1):
arm: dra7xx: Add hwmod data for MDIO and CPSW
Roger Quadros (1):
ARM: DRA7: hwmod: Add OCP2SCP3 module
Sathya Prakash M R (1):
ARM: AM43xx: hwmod: add DSS hwmod data
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/cm2_7xx.h | 4 +
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 40 ----
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 100 ++++++++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 260 +++++++++++++++++++++
.../mach-omap2/omap_hwmod_common_ipblock_data.c | 55 +++++
arch/arm/mach-omap2/prcm43xx.h | 1 +
arch/arm/mach-omap2/prm7xx.h | 4 +
8 files changed, 425 insertions(+), 40 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_common_ipblock_data.c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJTztWUAAoJEMePsQ0LvSpLjF4P/0PEGsq8ctRAQNaIKsVNtsDg
2plzao0Zk0hJjwTQ1HfcrGOiaMRwBpulmvb/hkFu4y7GDBiY2WEJn8d6qHDzbzLJ
2XJxfY69wtrQBs5SG587xNJSmDVoZXKZRbghM0fqJi3ip41bge5HtRD19VXVN5Rj
KZbKZVHWxtyVyZD1Lzl5lTufBgIgLG3nJUrkpIR5nPa0R9k2KtJMeFs88U578Nfs
XT6rQwKyFULqXCYoOOE1Kl2Wmo9mdeVEByx6GYUf0Qz5KES+3+2hiCBsc4FylVSO
tW695bfMgOQ186UZXSYxnQ2pDU/D1meVQ2IQVvlKyG7q+BPslWOgoeFgr1yVZkCz
wRPILUn6G6JRyJ/cCN8nYfrTnFXmV6Ve+Tb2BroHHkiJLPuxNEenFHkVHDaZgwYK
1zDoi1QAVUfy9cnic5yv2/Wd+5rxWwW2V9RCoAU4CT/sRrbH+kqMD1kR0U/Gr06k
L9nowkGwvTUO6aKtUjdsCRXKlThZLcjZcj+yGbDaF7V9UhGS1ys5bTgIXqGU8CDT
ZNg17MpslWTfL2NG6WFkSjU7DO2H8oO3D+o6pETSN6+h2SRkfLhxTjkILm6wSQVQ
HFgPE0fKNLWCRZZk8klAOiG6S4GlxK9S7lDAbVEgr4ivTShdH1p0EsjqDRu+ckPX
AJ8zX9YSxfEqcW/f08LX
=I+wx
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH v2 1/5] i2c: Don't start transfers when suspended
From: Russell King - ARM Linux @ 2014-07-22 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CEB196.9060903@ti.com>
On Tue, Jul 22, 2014 at 09:46:46PM +0300, Grygorii Strashko wrote:
> I'm not sure, this optimization is safe (
> Because, in many cases the access to PMIC IC needs to be allowed till late
> stages of suspending (at least till suspend_noirq stage or even later).
> For example, on some OMAP SoC Voltage management code need to use services
> provided by PMIC IC, which is connected to I2C.
This is definitely not safe. I worked on a PXA platform a while back
where the only way to tell the thing to "sleep" was to send an I2C
message to a microcontroller asking it to remove power.
Plus, as you say, you may also have PMICs that you need to talk to
in order to shut power off to various peripherals (and maybe even
the CPU itself) during the suspend process.
I2C is one of those cases where devices attached to the I2C bus are
themselves responsible for doing their own suspend shutdown at the
appropriate time; it's not the responsibility of the I2C core to
know this kind of system/driver dependent detail.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v3 2/2] ARM: shmobile: lager: enable USB PHY
From: Sergei Shtylyov @ 2014-07-22 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201407230113.46444.sergei.shtylyov@cogentembedded.com>
Enable USB PHY device for the Lager board.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 3:
- refreshed the patch.
Changes in version 2:
- refreshed the patch.
arch/arm/boot/dts/r8a7790-lager.dts | 4 ++++
1 file changed, 4 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7790-lager.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7790-lager.dts
+++ renesas/arch/arm/boot/dts/r8a7790-lager.dts
@@ -405,3 +405,7 @@
pinctrl-0 = <&usb2_pins>;
pinctrl-names = "default";
};
+
+&usbphy {
+ status = "okay";
+};
^ permalink raw reply
* [PATCH v3 1/2] ARM: shmobile: r8a7790: add USB PHY DT support
From: Sergei Shtylyov @ 2014-07-22 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201407230113.46444.sergei.shtylyov@cogentembedded.com>
Define the R8A7790 generic part of the USB PHY device node. It is up to the
board file to enable the device.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 3:
- changed subnodes of the USB PHY node to be per-channel;
- changed "renesas,phy-select" property to "reg" in the subnodes, and thus added
"#address-cells" and "#size-cells" properties to the parent node;
- moved "#phy-cells" property from the parent node to the subnodes, changing its
value to <1>;
- refreshed the patch.
Changes in version 2:
- added subnodes to the USB PHY node;
- refreshed the patch.
arch/arm/boot/dts/r8a7790.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7790.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7790.dtsi
+++ renesas/arch/arm/boot/dts/r8a7790.dtsi
@@ -505,6 +505,25 @@
status = "disabled";
};
+ usbphy: usb-phy at e6590100 {
+ compatible = "renesas,usb-phy-r8a7790";
+ reg = <0 0xe6590100 0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
+ clock-names = "usbhs";
+ status = "disabled";
+
+ usb0: usb-channel at 0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+ usb2: usb-channel at 2 {
+ reg = <2>;
+ #phy-cells = <1>;
+ };
+ };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
^ permalink raw reply
* [PATCH v2] ARM: AM43xx: hwmod: add DSS hwmod data
From: Paul Walmsley @ 2014-07-22 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1402994233-22599-1-git-send-email-tomi.valkeinen@ti.com>
On Tue, 17 Jun 2014, Tomi Valkeinen wrote:
> From: Sathya Prakash M R <sathyap@ti.com>
>
> Add DSS hwmod data for AM43xx.
>
> Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
> [tomi.valkeinen at ti.com: added missing dispc flags]
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Acked-by: Rajendra Nayak <rnayak@ti.com>
This one didn't compile on an AM43xx-only build:
----
arch/arm/mach-omap2/built-in.o:(.data+0x3f2c): undefined reference to `omap2_dss_hwmod_class'
arch/arm/mach-omap2/built-in.o:(.data+0x405c): undefined reference to `omap2_rfbi_hwmod_class'
make: *** [vmlinux] Error 1
test_build: Tue Jul 22 13:48:50 MDT 2014: FAILED on omap2plus_defconfig_am43xx_only hwmod-a-v3.17
----
Have queued the following patch instead.
- Paul
From: Sathya Prakash M R <sathyap@ti.com>
Date: Sat, 5 Jul 2014 17:44:57 -0600
Subject: [PATCH] ARM: AM43xx: hwmod: add DSS hwmod data
Add DSS hwmod data for AM43xx.
Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
[tomi.valkeinen at ti.com: added missing dispc flags]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Rajendra Nayak <rnayak@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Felipe Balbi <balbi@ti.com> # on linux-next 5f295cdf5c5d
[paul at pwsan.com: fixed build break on AM43xx-only config]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/Makefile | 1 +
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 40 ---------
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 100 +++++++++++++++++++++
.../mach-omap2/omap_hwmod_common_ipblock_data.c | 55 ++++++++++++
arch/arm/mach-omap2/prcm43xx.h | 1 +
5 files changed, 157 insertions(+), 40 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_common_ipblock_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8421f38cf445..75c73f253604 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -200,6 +200,7 @@ obj-$(CONFIG_SOC_OMAP2420) += opp2420_data.o
obj-$(CONFIG_SOC_OMAP2430) += opp2430_data.o
# hwmod data
+obj-y += omap_hwmod_common_ipblock_data.o
obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_ipblock_data.o
obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_3xxx_ipblock_data.o
obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_interconnect_data.o
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
index 5da7a42a6d90..c6c6384de867 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
@@ -37,46 +37,6 @@ struct omap_hwmod_class omap2_uart_class = {
};
/*
- * 'dss' class
- * display sub-system
- */
-
-static struct omap_hwmod_class_sysconfig omap2_dss_sysc = {
- .rev_offs = 0x0000,
- .sysc_offs = 0x0010,
- .syss_offs = 0x0014,
- .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
- SYSS_HAS_RESET_STATUS),
- .sysc_fields = &omap_hwmod_sysc_type1,
-};
-
-struct omap_hwmod_class omap2_dss_hwmod_class = {
- .name = "dss",
- .sysc = &omap2_dss_sysc,
- .reset = omap_dss_reset,
-};
-
-/*
- * 'rfbi' class
- * remote frame buffer interface
- */
-
-static struct omap_hwmod_class_sysconfig omap2_rfbi_sysc = {
- .rev_offs = 0x0000,
- .sysc_offs = 0x0010,
- .syss_offs = 0x0014,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
- .sysc_fields = &omap_hwmod_sysc_type1,
-};
-
-struct omap_hwmod_class omap2_rfbi_hwmod_class = {
- .name = "rfbi",
- .sysc = &omap2_rfbi_sysc,
-};
-
-/*
* 'venc' class
* video encoder
*/
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c2cc8083fdd..fea01aa3ef42 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,8 @@
#include "omap_hwmod.h"
#include "omap_hwmod_33xx_43xx_common_data.h"
#include "prcm43xx.h"
+#include "omap_hwmod_common_data.h"
+
/* IP blocks */
static struct omap_hwmod am43xx_l4_hs_hwmod = {
@@ -415,6 +417,72 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
},
};
+/* dss */
+
+static struct omap_hwmod am43xx_dss_core_hwmod = {
+ .name = "dss_core",
+ .class = &omap2_dss_hwmod_class,
+ .clkdm_name = "dss_clkdm",
+ .main_clk = "disp_clk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* dispc */
+
+struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
+ .manager_count = 1,
+ .has_framedonetv_irq = 0
+};
+
+static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
+ .rev_offs = 0x0000,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_MIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_dispc_hwmod_class = {
+ .name = "dispc",
+ .sysc = &am43xx_dispc_sysc,
+};
+
+static struct omap_hwmod am43xx_dss_dispc_hwmod = {
+ .name = "dss_dispc",
+ .class = &am43xx_dispc_hwmod_class,
+ .clkdm_name = "dss_clkdm",
+ .main_clk = "disp_clk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ },
+ },
+ .dev_attr = &am43xx_dss_dispc_dev_attr,
+};
+
+/* rfbi */
+
+static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
+ .name = "dss_rfbi",
+ .class = &omap2_rfbi_hwmod_class,
+ .clkdm_name = "dss_clkdm",
+ .main_clk = "disp_clk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ },
+ },
+};
+
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = &am33xx_l3_main_hwmod,
@@ -654,6 +722,34 @@ static struct omap_hwmod_ocp_if am43xx_l3_s__qspi = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_dss__l3_main = {
+ .master = &am43xx_dss_core_hwmod,
+ .slave = &am33xx_l3_main_hwmod,
+ .clk = "l3_gclk",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss = {
+ .master = &am33xx_l4_ls_hwmod,
+ .slave = &am43xx_dss_core_hwmod,
+ .clk = "l4ls_gclk",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_dispc = {
+ .master = &am33xx_l4_ls_hwmod,
+ .slave = &am43xx_dss_dispc_hwmod,
+ .clk = "l4ls_gclk",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = {
+ .master = &am33xx_l4_ls_hwmod,
+ .slave = &am43xx_dss_rfbi_hwmod,
+ .clk = "l4ls_gclk",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
&am33xx_l4_wkup__synctimer,
&am43xx_l4_ls__timer8,
@@ -748,6 +844,10 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
&am43xx_l4_ls__ocp2scp1,
&am43xx_l3_s__usbotgss0,
&am43xx_l3_s__usbotgss1,
+ &am43xx_dss__l3_main,
+ &am43xx_l4_ls__dss,
+ &am43xx_l4_ls__dss_dispc,
+ &am43xx_l4_ls__dss_rfbi,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_common_ipblock_data.c
new file mode 100644
index 000000000000..f21664da25a2
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_common_ipblock_data.c
@@ -0,0 +1,55 @@
+/*
+ * omap_hwmod_common_ipblock_data.c - common IP block data for OMAP2+
+ *
+ * Copyright (C) 2011 Nokia Corporation
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ * Paul Walmsley
+ *
+ * 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.
+ */
+
+#include "omap_hwmod.h"
+#include "omap_hwmod_common_data.h"
+
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap2_dss_sysc = {
+ .rev_offs = 0x0000,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+struct omap_hwmod_class omap2_dss_hwmod_class = {
+ .name = "dss",
+ .sysc = &omap2_dss_sysc,
+ .reset = omap_dss_reset,
+};
+
+/*
+ * 'rfbi' class
+ * remote frame buffer interface
+ */
+
+static struct omap_hwmod_class_sysconfig omap2_rfbi_sysc = {
+ .rev_offs = 0x0000,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+struct omap_hwmod_class omap2_rfbi_hwmod_class = {
+ .name = "rfbi",
+ .sysc = &omap2_rfbi_sysc,
+};
+
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index 7785be984edd..ad7b3e9977f8 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -142,5 +142,6 @@
#define AM43XX_CM_PER_USBPHYOCP2SCP0_CLKCTRL_OFFSET 0x05B8
#define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET 0x0268
#define AM43XX_CM_PER_USBPHYOCP2SCP1_CLKCTRL_OFFSET 0x05C0
+#define AM43XX_CM_PER_DSS_CLKCTRL_OFFSET 0x0a20
#endif
--
2.0.1
^ permalink raw reply related
* [PATCH v3 0/2] Add USB PHY device tree support for R8A7790/Lager board
From: Sergei Shtylyov @ 2014-07-22 21:13 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-v3.16-rc5-20140722' tag. Here we add the USB PHY device tree
support on the R8A7790/Lager reference board. The patchset requires the USB PHY
driver (just re-posted) in order to work.
[1/2] ARM: shmobile: r8a7790: add USB PHY DT support
[2/2] ARM: shmobile: lager: enable USB PHY
WBR, Sergei
^ permalink raw reply
* omap-wakeupgen.c: Remove function for fix me
From: Nick Krause @ 2014-07-22 21:09 UTC (permalink / raw)
To: linux-arm-kernel
static void __init irq_pm_init(void)
382 {
383 /* FIXME: Remove this when MPU OSWR support is added */
384 if (!soc_is_omap54xx())
385 cpu_pm_register_notifier(&irq_notifier_block);
386 }
I am wondering is this omap supported now if it is can I remove it?
Cheers Nick
^ permalink raw reply
* [PATCHv4 5/5] arm64: Add atomic pool for non-coherent and CMA allocations.
From: Catalin Marinas @ 2014-07-22 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201407222006.44666.arnd@arndb.de>
On Tue, Jul 22, 2014 at 07:06:44PM +0100, Arnd Bergmann wrote:
> On Wednesday 02 July 2014, Laura Abbott wrote:
> > + pgprot_t prot = __pgprot(PROT_NORMAL_NC);
> > + unsigned long nr_pages = atomic_pool_size >> PAGE_SHIFT;
> > + struct page *page;
> > + void *addr;
> > +
> > +
> > + if (dev_get_cma_area(NULL))
> > + page = dma_alloc_from_contiguous(NULL, nr_pages,
> > + get_order(atomic_pool_size));
> > + else
> > + page = alloc_pages(GFP_KERNEL, get_order(atomic_pool_size));
> > +
> > +
> > + if (page) {
> > + int ret;
> > +
> > + atomic_pool = gen_pool_create(PAGE_SHIFT, -1);
> > + if (!atomic_pool)
> > + goto free_page;
> > +
> > + addr = dma_common_contiguous_remap(page, atomic_pool_size,
> > + VM_USERMAP, prot, atomic_pool_init);
> > +
>
> I just stumbled over this thread and noticed the code here: When you do
> alloc_pages() above, you actually get pages that are already mapped into
> the linear kernel mapping as cacheable pages. Your new
> dma_common_contiguous_remap tries to map them as noncacheable. This
> seems broken because it allows the CPU to treat both mappings as
> cacheable, and that won't be coherent with device DMA.
It does *not* allow the CPU to treat both as cacheable. It treats the
non-cacheable mapping as non-cacheable (and the cacheable one as
cacheable). The only requirements the ARM ARM makes in this situation
(B2.9 point 5 in the ARMv8 ARM):
- Before writing to a location not using the Write-Back attribute,
software must invalidate, or clean, a location from the caches if any
agent might have written to the location with the Write-Back
attribute. This avoids the possibility of overwriting the location
with stale data.
- After writing to a location with the Write-Back attribute, software
must clean the location from the caches, to make the write visible to
external memory.
- Before reading the location with a cacheable attribute, software must
invalidate the location from the caches, to ensure that any value held
in the caches reflects the last value made visible in external memory.
So we as long as the CPU accesses such memory only via the non-cacheable
mapping, the only requirement is to flush the cache so that there are no
dirty lines that could be evicted.
(if the mismatched attributes were for example Normal vs Device, the
Device guarantees would be lost but in the cacheable vs non-cacheable
it's not too bad; same for ARMv7).
> > + if (!addr)
> > + goto destroy_genpool;
> > +
> > + memset(addr, 0, atomic_pool_size);
> > + __dma_flush_range(addr, addr + atomic_pool_size);
>
> It also seems weird to flush the cache on a virtual address of
> an uncacheable mapping. Is that well-defined?
Yes. According to D5.8.1 (Data and unified caches), "if cache
maintenance is performed on a memory location, the effect of that cache
maintenance is visible to all aliases of that physical memory location.
These properties are consistent with implementing all caches that can
handle data accesses as Physically-indexed, physically-tagged (PIPT)
caches".
> In the CMA case, the
> original mapping should already be uncached here, so you don't need
> to flush it.
I don't think it is non-cacheable already, at least not for arm64 (CMA
can be used on coherent architectures as well).
> In the alloc_pages() case, I think you need to unmap
> the pages from the linear mapping instead.
Even if unmapped, it would not remove dirty cache lines (which are
associated with physical addresses anyway). But we don't need to worry
about unmapping anyway, see above (that's unless we find some
architecture implementation where having such cacheable/non-cacheable
aliases is not efficient enough, the efficiency is not guaranteed by the
ARM ARM, just the correct behaviour).
--
Catalin
^ permalink raw reply
* [PATCH v5 1/8] of: Add NVIDIA Tegra SATA controller binding
From: Stephen Warren @ 2014-07-22 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718150603.GA7196@ulmo>
On 07/18/2014 09:06 AM, Thierry Reding wrote:
> On Fri, Jul 18, 2014 at 12:28:54PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 07/18/2014 09:16 AM, Mikko Perttunen wrote:
>>> So here's v5: this time, as suggested, I handle the sata clock myself and let ahci_platform handle it too, leading it to be prepared+enabled twice. This works fine, and allows us to remove the DT ordering requirement.
>>>
>>> I also have in the works a patchset that adds the name-based ahci_platform_get_resources function, but that is not quite ready yet, even if it is quite far along. Also, I am going on vacation and returning on 28.7., so if this v5 is acceptable maybe it could be merged for 3.17 and I could work on the new get_resources scheme after I get back from vacation?
>>
>> Yes that works for me v3 of all the patches with no newer version +
>> v5 of patch 1 and 7 are pretty clean and can go into 3.17 from my pov,
>> Tejun can you pick these up for 3.17 please?
>
> Tejun,
>
> I think the following patches can go through your tree without causing
> breakage through unresolved dependencies:
...
> Stephen, the rest of the patches would probably best go through the
> Tegra tree so that we can handle the dependencies there. I've already
> sent out pull requests for 3.17 today, but maybe Arnd and Olof can be
> convinced to take one more.
At this point, I'm just going to wait for 3.18 for anything that didn't
make it into 3.17.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140722/997fcbdb/attachment.sig>
^ permalink raw reply
* [PATCH v8 02/11] power: reset: Add reboot driver for brcmstb
From: Arnd Bergmann @ 2014-07-22 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722200213.GF28323@ld-irv-0074>
On Tuesday 22 July 2014 13:02:13 Brian Norris wrote:
> How about a third option, where we drop the 'select' statement and
> set POWER_RESET_BRCMSTB to be 'default y'? Then we don't have to modify
> the defconfig, and it gives the added bonus of choosing a sane default
> even if you're not based on the multi_v7_defconfig. i.e.:
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index 58c01aed9752..634de7b7fd28 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -94,7 +94,6 @@ config ARCH_BRCMSTB
> select MIGHT_HAVE_PCI
> select HAVE_SMP
> select HAVE_ARM_ARCH_TIMER
> - select POWER_RESET_BRCMSTB
> select BRCMSTB_GISB_ARB
> select BRCMSTB_L2_IRQ
> help
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index fcb9825debe5..ab5d57e2766d 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -23,6 +23,7 @@ config POWER_RESET_AXXIA
> config POWER_RESET_BRCMSTB
> bool "Broadcom STB reset driver"
> depends on POWER_RESET && ARCH_BRCMSTB
> + default y
> help
> This driver provides restart support for ARM-based Broadcom STB
> boards.
I don't like this too much. Why do you want to allow disabling the
driver if you make it 'default y' in the first place?
We try to avoid 'default y' for user-selectable drivers in general.
I noticed that in my example, I was missing the default. It should
have been
config POWER_RESET_BRCMSTB
bool "Broadcom STB reset driver" if COMPILE_TEST
depends on POWER_RESET && ARM
default ARCH_BRCMSTB
This way, it always gets selected when ARCH_BRCMSTB is on and
COMPILE_TEST is off. With COMPILE_TEST enabled, it defaults to
ARCH_BRCMSTB but can be enabled or disabled for the purpose
of compile testing.
Arnd
^ permalink raw reply
* [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support
From: Arnd Bergmann @ 2014-07-22 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722204431.GG28323@ld-irv-0074>
On Tuesday 22 July 2014 13:44:31 Brian Norris wrote:
> > For the platform changes in the first patch, I would prefer to have
> > Matt pick up the first patch, but we can also apply it directly into
> > arm-soc if he prefers that.
>
> That brings up a question related to PATCH 11 in the series (MAINTAINERS
> update); who will be maintaining arch/arm/mach-bcm/*brcmstb*, and how
> will code go upstream? It seems like Matt and Christian are officially
> mach-bcm maintainers, although I don't know if Christian is still
> involved.
You have to solve that question together with Matt. From my perspective
it would be easier if I only have to deal with one person for mach-bcm,
but it's really up to you.
> Also, BCM7xxx shares little in common with the rest of mach-bcm, except
> a company name, so we'd really like at least the 'Maintainer' entries
> for the CC. I was planning on a separate git tree too, although it could
> have conflicts if we touch arch/arm/mach-bcm/{Makefile,Kconfig}.
>
> So would we send a separate arm-soc pull request for the arm-soc
> targeted changes (and all future development)?
You can definitely have the separate MAINTAINERS entry without necessarily
becoming a maintainer at the same level. I know Matt is very responsive
and can forward your patches to arm-soc if that works for you.
> For the reset of mach-bcm stuff, I'll just send an arm-soc pull request
> soon enough, unless Matt/Arnd/Olof object.
I'll wait for Matt to comment before pulling it, otherwise that sounds
fine.
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: SoC changes for v3.17 (round 3)
From: Jason Cooper @ 2014-07-22 20:57 UTC (permalink / raw)
To: linux-arm-kernel
All,
Here's the cpufreq changes I mentioned over the weekend. It's been in
-next for a while. Once I get the new version of cpuidle from ThomasP,
I'll push that as quickly as possible.
As usual (do I need to type this each time any more? :) ), this is an
incremental pull request from tags/mvebu-soc-3.17-2 up to
tags/mvebu-soc-3.17-3 on the mvebu/soc branch.
Please pull.
thx,
Jason.
The following changes since commit ba364fc752daeded072a5ef31e43b84cb1f9e5fd:
ARM: Kirkwood: Remove mach-kirkwood (2014-07-13 22:13:39 +0000)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-soc-3.17-3
for you to fetch changes up to ba3ec5780bba27819bbc4f669e6c77418a00f14b:
Merge branch 'mvebu/soc-cpufreq' into mvebu/soc (2014-07-22 20:46:48 +0000)
----------------------------------------------------------------
mvebu SoC changes for v3.17 (round 3)
- mvebu:
- Add cpufreq support for Armada XP
----------------------------------------------------------------
Jason Cooper (1):
Merge branch 'mvebu/soc-cpufreq' into mvebu/soc
Thomas Petazzoni (3):
ARM: mvebu: ensure CPU clocks are enabled
ARM: mvebu: extend PMSU code to support dynamic frequency scaling
clk: mvebu: extend clk-cpu for dynamic frequency scaling
.../devicetree/bindings/clock/mvebu-cpu-clock.txt | 5 +-
arch/arm/mach-mvebu/platsmp.c | 1 +
arch/arm/mach-mvebu/pmsu.c | 162 +++++++++++++++++++++
drivers/clk/mvebu/clk-cpu.c | 80 +++++++++-
include/linux/mvebu-pmsu.h | 20 +++
5 files changed, 261 insertions(+), 7 deletions(-)
create mode 100644 include/linux/mvebu-pmsu.h
^ permalink raw reply
* [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support
From: Brian Norris @ 2014-07-22 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5675728.WLk3P96IBM@wuerfel>
+ Sebastian
On Tue, Jul 22, 2014 at 09:35:45AM +0200, Arnd Bergmann wrote:
> On Monday 21 July 2014 14:07:55 Brian Norris wrote:
> > I'm taking over the latest resubmission of this patch series.
> > There are a few moderate changes for v8 (noted below), but we
> > are waiting mostly for an Ack for the reboot driver.
> >
> > This patchset contains the board support package for the
> > Broadcom BCM7445 ARM-based SoC [1]. These changes contain a
> > minimal set of code needed for a BCM7445-based board to boot
> > the Linux kernel.
> >
> > These changes heavily leverage the OF/devicetree framework. The
> > machine is also built into the multi-platform ARMv7 image.
> >
> > Changes are also available here:
> >
> > https://github.com/brcm/linux/tree/brcmstb-v8
> > git://github.com/brcm/linux.git +brcmstb-v8
>
> Whole series
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Thanks!
> I think we should try to get this merged into 3.17, it's already
> taken too long and the patches look good.
Yes, it's about time.
> Please add the core architecture patches for arch/arm into Russell's
> patch tracker http://www.arm.linux.org.uk/developer/patches/.
OK, that's unfamiliar to me, but I'll try that out.
> For the platform changes in the first patch, I would prefer to have
> Matt pick up the first patch, but we can also apply it directly into
> arm-soc if he prefers that.
That brings up a question related to PATCH 11 in the series (MAINTAINERS
update); who will be maintaining arch/arm/mach-bcm/*brcmstb*, and how
will code go upstream? It seems like Matt and Christian are officially
mach-bcm maintainers, although I don't know if Christian is still
involved.
Also, BCM7xxx shares little in common with the rest of mach-bcm, except
a company name, so we'd really like at least the 'Maintainer' entries
for the CC. I was planning on a separate git tree too, although it could
have conflicts if we touch arch/arm/mach-bcm/{Makefile,Kconfig}.
So would we send a separate arm-soc pull request for the arm-soc
targeted changes (and all future development)?
> The reset driver can ideally go through the drivers/power/ maintainers,
> but if they are not interested in merging it, we can also take that
> through arm-soc.
I don't see much activity from the drivers/power/ maintainers on the
mailing lists, and I know David Woodhouse at least has been severely
distracted (I took over for him on driver/mtd/ recently), so I don't
expect much. (EDIT: I see [1]. Nice!)
> See also my one comment on that driver.
I proposed an additional diff on that patch in response.
I can strip the drivers/power/reboot/ driver out and send it separately
to our new drivers/power/ maintainer (thanks Sebastian!), and hope that
it gets through for 3.17.
For the reset of mach-bcm stuff, I'll just send an arm-soc pull request
soon enough, unless Matt/Arnd/Olof object.
Thanks,
Brian
[1] https://lkml.org/lkml/2014/7/16/539
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: major refresh
From: Olof Johansson @ 2014-07-22 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12165027.MHmNZOI7jc@wuerfel>
On Tue, Jul 22, 2014 at 11:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 22 July 2014 11:01:10 Olof Johansson wrote:
>> This is a major refresh of the multi_v7_defconfig:
>>
>> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
>> * Enable big.LITTLE
>> * MCPM
>> * CYAPA touchpad
>> * Samsung-related MTD/regulator/clk/pinmux drivers
>> * Add some of the CrOS EC drivers
>> - Turn on TPM, HW_RANDOM
>> - OMAP_USB3 -> TI_PIPE3 option rename
>> - Enable MCPM/b.L for VEXPRESS
>> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
>> - CONFIG_LOGO, because penguins.
>>
>> I took care to keep the new options that have been added for whose the
>> drivers are not yet in our for-next branch. This was pretty awkward so
>> we should sort out how to handle those better in the future.
>
> Since you've already done all those, how about enabling THUMB2_KERNEL?
> For the multi_v7_defconfig, it should actually give some benefits,
> since it's rather large, and it would be good to have some more testing
> with this option enabled.
>
> I guess the first step would be to enable it and just see if your
> boot farm survives the change.
Good point, I'll definitely give that a go once the current issues are resolved.
Which are: These changes make 5250-based machines (snow and arndale)
break. Lots of i2c timeouts on SATA and hdmi-phy. Looks like arndale
might be missing pinctrl setups for it?
Tushar, Kukjin, any chance you can investigate from your end? I'd like
to get this change in since it allows for better multiplatform
coverage, but the Exynos breakage must be fixed...
-Olof
^ permalink raw reply
* [PATCH v5 0/3] arm64: Add seccomp support
From: Kees Cook @ 2014-07-22 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406020499-5537-1-git-send-email-takahiro.akashi@linaro.org>
On Tue, Jul 22, 2014 at 2:14 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> (Please apply this patch after my audit patch in order to avoid some
> conflict on arm64/Kconfig.)
>
> This patch enables secure computing (system call filtering) on arm64.
> System calls can be allowed or denied by loaded bpf-style rules.
> Architecture specific part is to run secure_computing() on syscall entry
> and check the result. See [3/3]
Thanks for working on this!
> Prerequisites are:
> * "arm64: Add audit support" patch
>
> This code is tested on ARMv8 fast model using
> * libseccomp v2.1.1 with modifications for arm64 and verified by its "live"
> tests, 20, 21 and 24.
> * modified version of Kees' seccomp test for 'changing/skipping a syscall'
> behavior
Would you be able to share this? I'd love to add it to the seccomp
regression suite for the arm64-specific parts.
Thanks!
-Kees
>
> Changes v4 -> v5:
> * rebased to v3.16-rc
> * add patch [1/3] to allow ptrace to change a system call
> (please note that this patch should be applied even without seccomp.)
>
> Changes v3 -> v4:
> * removed the following patch and moved it to "arm64: prerequisites for
> audit and ftrace" patchset since it is required for audit and ftrace in
> case of !COMPAT, too.
> "arm64: is_compat_task is defined both in asm/compat.h and linux/compat.h"
>
> Changes v2 -> v3:
> * removed unnecessary 'type cast' operations [2/3]
> * check for a return value (-1) of secure_computing() explicitly [2/3]
> * aligned with the patch, "arm64: split syscall_trace() into separate
> functions for enter/exit" [2/3]
> * changed default of CONFIG_SECCOMP to n [2/3]
>
> Changes v1 -> v2:
> * added generic seccomp.h for arm64 to utilize it [1,2/3]
> * changed syscall_trace() to return more meaningful value (-EPERM)
> on seccomp failure case [2/3]
> * aligned with the change in "arm64: make a single hook to syscall_trace()
> for all syscall features" v2 [2/3]
> * removed is_compat_task() definition from compat.h [3/3]
>
> AKASHI Takahiro (3):
> arm64: ptrace: reload a syscall number after ptrace operations
> asm-generic: Add generic seccomp.h for secure computing mode 1
> arm64: Add seccomp support
>
> arch/arm64/Kconfig | 14 ++++++++++++++
> arch/arm64/include/asm/seccomp.h | 25 +++++++++++++++++++++++++
> arch/arm64/include/asm/unistd.h | 3 +++
> arch/arm64/kernel/entry.S | 2 ++
> arch/arm64/kernel/ptrace.c | 18 ++++++++++++++++++
> include/asm-generic/seccomp.h | 28 ++++++++++++++++++++++++++++
> 6 files changed, 90 insertions(+)
> create mode 100644 arch/arm64/include/asm/seccomp.h
> create mode 100644 include/asm-generic/seccomp.h
>
> --
> 1.7.9.5
>
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* [PATCH 0/6] net: mvpp2: Assorted fixes
From: David Miller @ 2014-07-22 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722144519.GA682@arch.cereza>
From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Date: Tue, 22 Jul 2014 11:45:19 -0300
> On 21 Jul 08:27 PM, David Miller wrote:
>> From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>> Date: Mon, 21 Jul 2014 13:48:10 -0300
>>
>> > This patchset contains a set of fixes for issues found while doing some
>> > more intensive tests on the recently accepted mvpp2 ethernet driver.
>> >
>> > David: if we are still in time, we'd like to get the driver fixes merged
>> > for v3.17-rc1.
>> >
>> > For the devicetree changes, it's already too late for that, since Jason
>> > Cooper has already posted the PRs for v3.17. I'll re-post them when
>> > v3.17-rc1 is released.
>> >
>> > As usual, feedback is welcome.
>>
>> This series does not apply to the 'net' tree at all, please respin
>> and resubmit.
>
> This series applies on net-next.
>
> Sorry for not mentioning it,
They are bonafide bug fixes, therefore should be targetted at 'net'.
^ permalink raw reply
* [v3 PATCH 1/6] drivers: reset: TI: SoC reset controller support.
From: Suman Anna @ 2014-07-22 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405615531-15649-1-git-send-email-dmurphy@ti.com>
Hi Dan,
On 07/17/2014 11:45 AM, Murphy, Dan wrote:
> The TI SoC reset controller support utilizes the
> reset controller framework to give device drivers or
> function drivers a common set of APIs to call to reset
> a module.
>
> The reset-ti is a common interface to the reset framework.
> The register data is retrieved during initialization
> of the reset driver through the reset-ti-data
> file. The array of data is associated with the compatible from the
> respective DT entry.
Outdated commit description, this is no longer correct.
>
> Once the data is available then this is derefenced within the common
> interface.
>
> The device driver has the ability to assert, deassert or perform a
> complete reset.
>
> This code was derived from previous work by Rajendra Nayak and Afzal Mohammed.
> The code was changed to adopt to the reset core and abstract away the SoC information.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v3 - Resolved comments from v2. To many to call out here - https://patchwork.kernel.org/patch/4116941/
Please add a cover letter for the series next time and make sure you cc
the reset driver maintainer.
>
> drivers/reset/Kconfig | 9 ++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-ti.c | 373 ++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 383 insertions(+)
> create mode 100644 drivers/reset/reset-ti.c
>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 0615f50..31a5a79 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -12,4 +12,13 @@ menuconfig RESET_CONTROLLER
>
> If unsure, say no.
>
> +config RESET_TI
> + depends on RESET_CONTROLLER && ARCH_OMAP || COMPILE_TEST
> + bool "TI reset controller"
> + help
> + Reset controller support for TI SoC's
> +
> + Reset controller found in TI's AM series of SoC's like
> + AM335x and AM43x and OMAP SoC's like OMAP5 and DRA7
> +
> source "drivers/reset/sti/Kconfig"
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 60fed3d..a5986b9 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_RESET_CONTROLLER) += core.o
> obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
> obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
> +obj-$(CONFIG_RESET_TI) += reset-ti.o
> obj-$(CONFIG_ARCH_STI) += sti/
> diff --git a/drivers/reset/reset-ti.c b/drivers/reset/reset-ti.c
> new file mode 100644
> index 0000000..e9d4039
> --- /dev/null
> +++ b/drivers/reset/reset-ti.c
> @@ -0,0 +1,373 @@
> +/*
> + * reset-ti.c - PRCM reset driver for TI SoC's
> + *
> + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
> + *
> + * Author: Dan Murphy <dmurphy@ti.com>
> + *
> + * 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.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
This header is no longer needed, now that you are not using of_iomap.
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset.h>
> +#include <linux/reset-controller.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +
> +#define DRIVER_NAME "prcm_reset_ti"
> +#define MAX_RESET_SIGNALS 255
This sounds like a lot, I think you should reduce this to not waste
memory. Start with a small number, and add a trace for increasing this
if you run out of the current slots.
> +
> +/**
> + * struct ti_reset_reg_data - Structure of the reset register information
> + * for a particular SoC.
> + * @rstctrl_offs: This is the reset control offset value from
> + * from the parent reset node.
> + * @rstst_offs: This is the reset status offset value from
> + * from the parent reset node.
> + * @rstctrl_bit: This is the reset control bit for the module.
> + * @rstst_bit: This is the reset status bit for the module.
> + *
> + * Longer description of this structure.
> + */
> +struct ti_reset_reg_data {
> + phandle handle;
> + u32 rstctrl_offs;
> + u32 rstst_offs;
> + u32 rstctrl_bit;
> + u32 rstst_bit;
> +};
> +
> +/**
> + * struct ti_reset_data - Structure that contains the reset register data
> + * as well as the total number of resets for a particular SoC.
> + * @ti_data: Pointer to this structure to be dereferenced
> + * @reg_data: Pointer to the register data structure.
> + * @rcdev: Reset controller device instance
> + * @dev: Pointer to the devive structure
> + * @ti_reg_data: Array of register data. Only reset signal with valid
> + * phandles will be stored in this array.
> + * @reg_base: Parent register base address
> + * @lock: Spinlock for accessing the registers
> + * @nr_resets: Total number of resets for the SoC in the reset array.
> + *
> + * This structure contains a pointer to the register data and the modules
> + * register base. The number of resets and reset controller device data is
> + * stored within this structure.
> + *
> + */
> +struct ti_reset_data {
> + struct ti_reset_data *ti_data;
I initially thought this was for list management to deal with multiple
reset nodes, but why do we need this self-referencing pointer?
> + struct ti_reset_reg_data *reg_data;
What do you need this for? I haven't seen it getting used anywhere, and
ti_reg_data looks very similar.
> + struct reset_controller_dev rcdev;
> + struct device *dev;
> + struct ti_reset_reg_data ti_reg_data[MAX_RESET_SIGNALS];
> + void __iomem *reg_base;
> + spinlock_t lock;
> + int nr_resets;
> +};
> +
> +static int ti_reset_wait_on_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct ti_reset_data *reset_data = container_of(rcdev,
> + struct ti_reset_data,
> + rcdev);
> + void __iomem *status_reg = reset_data->reg_base;
> + u32 bit_mask = 0;
> + u32 val = 0;
> + unsigned long flags;
> + int i = 1000;
> + int ret = 0;
> +
> + spin_lock_irqsave(&reset_data->lock, flags);
> + /* Clear the reset status bit to reflect the current status */
> + status_reg = reset_data->reg_base + reset_data->ti_reg_data[id].rstst_offs;
> + bit_mask = reset_data->ti_reg_data[id].rstst_bit;
> +
> + do {
> + val = readl(status_reg);
> + } while (--i && (val & (1 << bit_mask)));
Others have already pointed this out, I believe you want something
equivalent to omap_test_timeout here. Please check with Tero if that
would be available, otherwise, you can define the same in this file.
> +
> + if (i == 0 && val & (1 << bit_mask)) {
> + dev_err(reset_data->dev, "%s: Reset failed\n", __func__);
> + ret = -EIO;
> + }
> +
> + spin_unlock_irqrestore(&reset_data->lock, flags);
> + return ret;
> +}
> +
> +static int ti_reset_assert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct ti_reset_data *reset_data = container_of(rcdev,
> + struct ti_reset_data,
> + rcdev);
> + void __iomem *reg;
> + void __iomem *status_reg;
> + u32 status_bit = 0;
> + u32 bit_mask = 0;
> + u32 val = 0;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&reset_data->lock, flags);
> +
> + /* Clear the reset status bit to reflect the current status */
> + status_reg = reset_data->reg_base + reset_data->ti_reg_data[id].rstst_offs;
> + status_bit = reset_data->ti_reg_data[id].rstst_bit;
> + writel(1 << status_bit, status_reg);
> +
> + reg = reset_data->reg_base + reset_data->ti_reg_data[id].rstctrl_offs;
> + bit_mask = reset_data->ti_reg_data[id].rstctrl_bit;
> + val = readl(reg);
> + if (!(val & bit_mask)) {
> + val |= bit_mask;
> + writel(val, reg);
> + }
> +
> + spin_unlock_irqrestore(&reset_data->lock, flags);
> + return 0;
> +}
> +
> +static int ti_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> +
> + struct ti_reset_data *reset_data = container_of(rcdev,
> + struct ti_reset_data,
> + rcdev);
> + void __iomem *reg;
> + void __iomem *status_reg;
> + u32 status_bit = 0;
> + u32 bit_mask = 0;
> + u32 val = 0;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&reset_data->lock, flags);
> +
> + /* Clear the reset status bit to reflect the current status */
> + status_reg = reset_data->reg_base + reset_data->ti_reg_data[id].rstst_offs;
> + status_bit = reset_data->ti_reg_data[id].rstst_bit;
> + writel(1 << status_bit, status_reg);
Is there a need for clearing the reset status both in assert and deassert?
> +
> + reg = reset_data->reg_base + reset_data->ti_reg_data[id].rstctrl_offs;
> + bit_mask = reset_data->ti_reg_data[id].rstctrl_bit;
> + val = readl(reg);
> + if (val & bit_mask) {
> + val &= ~bit_mask;
> + writel(val, reg);
> + }
> +
> + spin_unlock_irqrestore(&reset_data->lock, flags);
> +
> + return 0;
> +}
> +
> +static int ti_reset_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + ti_reset_assert(rcdev, id);
> + ti_reset_deassert(rcdev, id);
> +
> + return ti_reset_wait_on_reset(rcdev, id);
> +}
> +
> +static int ti_reset_xlate(struct reset_controller_dev *rcdev,
> + const struct of_phandle_args *reset_spec)
> +{
> +
> + struct ti_reset_data *reset_data = container_of(rcdev,
> + struct ti_reset_data,
> + rcdev);
> + struct device_node *dev_node;
> + int i;
> +
> + if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
> + return -EINVAL;
> +
> + /* Verify that the phandle exists */
> + dev_node = of_find_node_by_phandle((phandle) reset_spec->args[0]);
> + if (!dev_node) {
> + dev_err(reset_data->dev,
> + "%s: Cannot find phandle node\n",
> + __func__);
> + return -EINVAL;
> + }
> +
> + for (i = 0; i <= reset_data->nr_resets; i++) {
> + if (reset_data->ti_reg_data[i].handle == dev_node->phandle)
> + return i;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static struct reset_control_ops ti_reset_ops = {
> + .reset = ti_reset_reset,
> + .assert = ti_reset_assert,
> + .deassert = ti_reset_deassert,
> +};
> +
> +static int ti_reset_populate_child(struct ti_reset_data *reset_data,
> + struct device_node *reset_child,
> + u32 ctrl_offs, u32 status_offs)
> +{
> + struct device_node *next_reset_child = NULL;
> + int i = reset_data->nr_resets;
> + int ret;
> + u32 ctrl_bit;
> +
> + while ((next_reset_child = of_get_next_child(reset_child, next_reset_child))) {
Add a check for array bounds on the ti_reg_data array here, rather than
choosing a large number to begin with.
> + if (next_reset_child->phandle) {
> + /* Get the bits of each sub-reset */
> + ret = of_property_read_u32(next_reset_child, "control-bit",
> + &ctrl_bit);
> + if (ret < 0) {
> + dev_err(reset_data->dev,
> + "%s: No entry in %s for rstctrl_offs\n",
> + __func__, next_reset_child->name);
> +
> + return -ENODEV;
> + }
> +
> + ret = of_property_read_u32(next_reset_child, "status-bit",
> + &reset_data->ti_reg_data[i].rstst_bit);
> + if (ret < 0) {
> + dev_err(reset_data->dev,
> + "%s: No entry in %s for rstst_offs\n",
> + __func__, next_reset_child->name);
> +
> + return -ENODEV;
> + }
> +
> + reset_data->ti_reg_data[i].rstctrl_offs = ctrl_offs;
> + reset_data->ti_reg_data[i].rstst_offs = status_offs;
> + reset_data->ti_reg_data[i].handle = next_reset_child->phandle;
> + i++;
> + }
> + };
> +
> + reset_data->nr_resets = i;
> +
> + return 0;
> +}
> +
> +static int ti_reset_get_of_data(struct ti_reset_data *reset_data,
> + struct device_node *dev_node)
> +{
> + struct device_node *reset_child = NULL;
> + int ret = -EINVAL;
> + u32 ctrl_offs, status_offs;
> +
> + /* Loop through all the children and populate a lookup array */
> + while ((reset_child = of_get_next_child(dev_node, reset_child))) {
> + ret = of_property_read_u32_index(reset_child, "reg", 0,
> + &ctrl_offs);
> + if (ret)
> + return ret;
> +
> + ret = of_property_read_u32_index(reset_child, "reg", 1,
> + &status_offs);
> + if (ret)
> + return ret;
> +
> + ret = ti_reset_populate_child(reset_data, reset_child,
> + ctrl_offs, status_offs);
> + if (ret)
> + return ret;
> + };
> +
> + return 0;
> +}
> +
> +static int ti_reset_probe(struct platform_device *pdev)
> +{
> + struct device_node *resets;
> + struct ti_reset_data *reset_data;
> + struct resource *res;
> + int ret;
> +
> + reset_data = devm_kzalloc(&pdev->dev, sizeof(*reset_data), GFP_KERNEL);
> + if (!reset_data)
> + return -ENOMEM;
> +
> + resets = of_find_node_by_name(NULL, "resets");
> + if (!resets) {
> + dev_err(&pdev->dev, "%s: missing 'resets' child node.\n",
> + __func__);
> + return -EINVAL;
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + reset_data->reg_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(reset_data->reg_base)) {
> + dev_err(&pdev->dev, "%s: Cannot map reset parent.\n", __func__);
> + return -ENODEV;
> + }
If the PRM node address is accessed by someone else as well, then this
will always fail.
> +
> + spin_lock_init(&reset_data->lock);
> + reset_data->dev = &pdev->dev;
> + ret = ti_reset_get_of_data(reset_data, resets);
> + if (ret)
> + return -EINVAL;
> +
> + reset_data->rcdev.owner = THIS_MODULE;
> + reset_data->rcdev.of_node = resets;
> + reset_data->rcdev.ops = &ti_reset_ops;
> +
> + reset_data->rcdev.of_reset_n_cells = 1;
> + reset_data->rcdev.of_xlate = &ti_reset_xlate;
> +
> + reset_data->ti_data = reset_data;
> +
> + platform_set_drvdata(pdev, reset_data);
> +
> + reset_controller_register(&reset_data->rcdev);
> +
> + return 0;
> +}
> +
> +static int ti_reset_remove(struct platform_device *pdev)
> +{
> + struct ti_reset_data *reset_data;
> +
> + reset_data = platform_get_drvdata(pdev);
> + reset_controller_unregister(&reset_data->rcdev);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ti_reset_of_match[] = {
> + { .compatible = "ti,omap5-prm" },
> + { .compatible = "ti,omap4-prm" },
> + { .compatible = "ti,omap5-prm" },
Duplicate entry
> + { .compatible = "ti,dra7-prm" },
> + { .compatible = "ti,am4-prcm" },
> + { .compatible = "ti,am3-prcm" },
> + {},
> +};
You are using the parent SoC parent nodes as the compatibles, but
this has to restricted to just the resets. I believe this driver is
designed only to deal with the reset nodes under those PRM/PRCM nodes -
we won't be handling all the other nodes under these PRM/PRCM nodes.
Please also see Tony's comment about working with Tero's PRM cleanup.
regards
Suman
> +
> +static struct platform_driver ti_reset_driver = {
> + .probe = ti_reset_probe,
> + .remove = ti_reset_remove,
> + .driver = {
> + .name = DRIVER_NAME,
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(ti_reset_of_match),
> + },
> +};
> +module_platform_driver(ti_reset_driver);
> +
> +MODULE_DESCRIPTION("PRCM reset driver for TI SoCs");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:" DRIVER_NAME);
>
^ permalink raw reply
* [PATCH v5 1/3] arm64: ptrace: reload a syscall number after ptrace operations
From: Kees Cook @ 2014-07-22 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406020499-5537-2-git-send-email-takahiro.akashi@linaro.org>
On Tue, Jul 22, 2014 at 2:14 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> Arm64 holds a syscall number in w8(x8) register. Ptrace tracer may change
> its value either to:
> * any valid syscall number to alter a system call, or
> * -1 to skip a system call
>
> This patch implements this behavior by reloading that value into syscallno
> in struct pt_regs after tracehook_report_syscall_entry() or
> secure_computing(). In case of '-1', a return value of system call can also
> be changed by the tracer setting the value to x0 register, and so
> sys_ni_nosyscall() should not be called.
>
> See also:
> 42309ab4, ARM: 8087/1: ptrace: reload syscall number after
> secure_computing() check
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> ---
> arch/arm64/kernel/entry.S | 2 ++
> arch/arm64/kernel/ptrace.c | 13 +++++++++++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 5141e79..de8bdbc 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -628,6 +628,8 @@ ENDPROC(el0_svc)
> __sys_trace:
> mov x0, sp
> bl syscall_trace_enter
> + cmp w0, #-1 // skip syscall?
> + b.eq ret_to_user
> adr lr, __sys_trace_return // return address
> uxtw scno, w0 // syscall number (possibly new)
> mov x1, sp // pointer to regs
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index 70526cf..100d7d1 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -21,6 +21,7 @@
>
> #include <linux/audit.h>
> #include <linux/compat.h>
> +#include <linux/errno.h>
> #include <linux/kernel.h>
> #include <linux/sched.h>
> #include <linux/mm.h>
> @@ -1109,9 +1110,21 @@ static void tracehook_report_syscall(struct pt_regs *regs,
>
> asmlinkage int syscall_trace_enter(struct pt_regs *regs)
> {
> + unsigned long saved_x0, saved_x8;
> +
> + saved_x0 = regs->regs[0];
> + saved_x8 = regs->regs[8];
> +
> if (test_thread_flag(TIF_SYSCALL_TRACE))
> tracehook_report_syscall(regs, PTRACE_SYSCALL_ENTER);
>
> + regs->syscallno = regs->regs[8];
> + if ((long)regs->syscallno == ~0UL) { /* skip this syscall */
> + regs->regs[8] = saved_x8;
> + if (regs->regs[0] == saved_x0) /* not changed by user */
> + regs->regs[0] = -ENOSYS;
I'm not sure this is right compared to other architectures. Generally
when a tracer performs a syscall skip, it's up to them to also adjust
the return value. They may want to be faking a syscall, and what if
the value they want to return happens to be what x0 was going into the
tracer? It would have no way to avoid this -ENOSYS case. I think
things are fine without this test.
-Kees
> + }
> +
> if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
> trace_sys_enter(regs, regs->syscallno);
>
> --
> 1.7.9.5
>
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* [PATCH v8 02/11] power: reset: Add reboot driver for brcmstb
From: Brian Norris @ 2014-07-22 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <62122849.RXJHvac7Iy@wuerfel>
On Tue, Jul 22, 2014 at 09:28:39AM +0200, Arnd Bergmann wrote:
> On Monday 21 July 2014 14:07:57 Brian Norris wrote:
> > diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> > index 0073633e7699..9782e8d80647 100644
> > --- a/arch/arm/mach-bcm/Kconfig
> > +++ b/arch/arm/mach-bcm/Kconfig
> > @@ -94,6 +94,7 @@ config ARCH_BRCMSTB
> > select MIGHT_HAVE_PCI
> > select HAVE_SMP
> > select HAVE_ARM_ARCH_TIMER
> > + select POWER_RESET_BRCMSTB
> > help
> > Say Y if you intend to run the kernel on a Broadcom ARM-based STB
> > chipset.
> > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> > index bdcf5173e377..fcb9825debe5 100644
> > --- a/drivers/power/reset/Kconfig
> > +++ b/drivers/power/reset/Kconfig
> > @@ -20,6 +20,16 @@ config POWER_RESET_AXXIA
> >
> > Say Y if you have an Axxia family SoC.
> >
> > +config POWER_RESET_BRCMSTB
> > + bool "Broadcom STB reset driver"
> > + depends on POWER_RESET && ARCH_BRCMSTB
> > + help
> > + This driver provides restart support for ARM-based Broadcom STB
> > + boards.
> > +
> > + Say Y here if you have an ARM-based Broadcom STB board and you wish
> > + to have restart support.
> > +
> > config POWER_RESET_GPIO
> > bool "GPIO power-off driver"
> > depends on OF_GPIO && POWER_RESET
> >
>
> (nitpicking)
>
> You shouldn't have both a user-selectable option and 'select' it from
> the platform, because it makes it inherently not selectable, in particular
> in the combination with 'depends on ARCH_BRCMSTB'.
OK, thanks for the comment. Note that there is some precedent for this
bad Kconfig behavior in the same subsystem (POWER_RESET_GPIO and
POWER_RESET_VEXPRESS are both 'select'ed in arch/arm/mach-*/Kconfig).
[...]
> My preference in this case however would be to just drop the 'select'
> statement and add the driver to the defconfig file.
How about a third option, where we drop the 'select' statement and
set POWER_RESET_BRCMSTB to be 'default y'? Then we don't have to modify
the defconfig, and it gives the added bonus of choosing a sane default
even if you're not based on the multi_v7_defconfig. i.e.:
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 58c01aed9752..634de7b7fd28 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -94,7 +94,6 @@ config ARCH_BRCMSTB
select MIGHT_HAVE_PCI
select HAVE_SMP
select HAVE_ARM_ARCH_TIMER
- select POWER_RESET_BRCMSTB
select BRCMSTB_GISB_ARB
select BRCMSTB_L2_IRQ
help
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index fcb9825debe5..ab5d57e2766d 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -23,6 +23,7 @@ config POWER_RESET_AXXIA
config POWER_RESET_BRCMSTB
bool "Broadcom STB reset driver"
depends on POWER_RESET && ARCH_BRCMSTB
+ default y
help
This driver provides restart support for ARM-based Broadcom STB
boards.
Brian
^ permalink raw reply related
* [PATCH v2 2/7] arm: dts: omap3-gta04: Fix magnetometer model
From: Marek Belisko @ 2014-07-22 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406057420-22269-3-git-send-email-marek@goldelico.com>
gta04 is using hmc5883l not hmc5843 so fix wrong compatible
entry.
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
arch/arm/boot/dts/omap3-gta04.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index 7d7ddd7..4067495 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -220,7 +220,7 @@
/* compass aka magnetometer */
hmc5843 at 1e {
- compatible = "honeywell,hmc5843";
+ compatible = "honeywell,hmc5883l";
reg = <0x1e>;
};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/7] arm: dts: omap3-gta04: Fix magnetometer model
From: Belisko Marek @ 2014-07-22 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.01.1407222145360.27558@pmeerw.net>
On Tue, Jul 22, 2014 at 9:46 PM, Peter Meerwald <pmeerw@pmeerw.net> wrote:
>
>> gta04 is using hmc5843l not hmc5843 so fix wrong compatible
>> entry.
>
> I guess you mean hmc5883l
Ah right. Thanks. I'll post update version.
>
>> Signed-off-by: Marek Belisko <marek@goldelico.com>
>> ---
>> arch/arm/boot/dts/omap3-gta04.dts | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
>> index 7d7ddd7..6d1a8d8 100644
>> --- a/arch/arm/boot/dts/omap3-gta04.dts
>> +++ b/arch/arm/boot/dts/omap3-gta04.dts
>> @@ -220,7 +220,7 @@
>>
>> /* compass aka magnetometer */
>> hmc5843 at 1e {
>> - compatible = "honeywell,hmc5843";
>> + compatible = "honeywell,hmc5843l";
>> reg = <0x1e>;
>> };
>>
>>
>
> --
>
> Peter Meerwald
> +43-664-2444418 (mobile)
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* [PATCH v2 2/7] arm: dts: omap3-gta04: Fix magnetometer model
From: Peter Meerwald @ 2014-07-22 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406057420-22269-3-git-send-email-marek@goldelico.com>
> gta04 is using hmc5843l not hmc5843 so fix wrong compatible
> entry.
I guess you mean hmc5883l
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
> arch/arm/boot/dts/omap3-gta04.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
> index 7d7ddd7..6d1a8d8 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dts
> +++ b/arch/arm/boot/dts/omap3-gta04.dts
> @@ -220,7 +220,7 @@
>
> /* compass aka magnetometer */
> hmc5843 at 1e {
> - compatible = "honeywell,hmc5843";
> + compatible = "honeywell,hmc5843l";
> reg = <0x1e>;
> };
>
>
--
Peter Meerwald
+43-664-2444418 (mobile)
^ permalink raw reply
* [PATCH v3] platform: Make platform_bus device a platform device
From: Olof Johansson @ 2014-07-22 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406051719-17354-1-git-send-email-pawel.moll@arm.com>
Hi,
On Tue, Jul 22, 2014 at 10:55 AM, Pawel Moll <pawel.moll@arm.com> wrote:
> ... describing the root of the device tree, so one can write
> a platform driver initializing the platform.
>
> There has been a lot of references to platform_bus device where
> it didn't make any sense, because simply using NULL as a parent
> will make the device be adopted by the top level anyway.
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> ---
> Changes since v2:
>
> * replaced references to platform_bus.dev with NULL
> in places where it shouldn't make any difference
>
> Changes since v1:
>
> * rebased on top of v3.16-rc6
>
> * fixed up all new explicit references to platform_bus,
> with majority in mach-shmobile; 99% of them seem completely
> useless and I was *very* tempted to replace them with
> NULL - all reasons for and against this are welcomed
>
> arch/arm/mach-bcm/board_bcm21664.c | 3 +--
> arch/arm/mach-bcm/board_bcm281xx.c | 3 +--
> arch/arm/mach-clps711x/board-edb7211.c | 6 +++---
> arch/arm/mach-clps711x/board-p720t.c | 6 +++---
> arch/arm/mach-imx/devices/devices.c | 4 ++--
> arch/arm/mach-imx/mach-mx27ads.c | 2 +-
> arch/arm/mach-shmobile/board-ape6evm.c | 14 +++++++-------
> arch/arm/mach-shmobile/board-bockw.c | 19 ++++++++----------
> arch/arm/mach-shmobile/board-genmai.c | 5 ++---
> arch/arm/mach-shmobile/board-koelsch.c | 26 ++++++++++++-------------
> arch/arm/mach-shmobile/board-lager.c | 34 ++++++++++++++-------------------
> arch/arm/mach-shmobile/board-marzen.c | 1 -
> arch/arm/mach-shmobile/setup-r7s72100.c | 2 +-
> arch/arm/mach-shmobile/setup-r8a73a4.c | 8 ++++----
> arch/arm/mach-shmobile/setup-r8a7778.c | 13 ++++++-------
> arch/arm/mach-shmobile/setup-r8a7779.c | 6 +++---
> arch/arm/mach-shmobile/setup-r8a7790.c | 10 +++++-----
> arch/arm/mach-shmobile/setup-r8a7791.c | 8 ++++----
> arch/unicore32/kernel/puv3-core.c | 2 +-
> arch/unicore32/kernel/puv3-nb0916.c | 6 +++---
> drivers/base/platform.c | 18 +++++++++++------
> drivers/char/tile-srom.c | 2 +-
> drivers/mmc/host/sdhci-pltfm.c | 2 +-
> drivers/scsi/hosts.c | 2 +-
> include/linux/platform_device.h | 2 +-
> 25 files changed, 97 insertions(+), 107 deletions(-)
>
> diff --git a/arch/arm/mach-bcm/board_bcm21664.c b/arch/arm/mach-bcm/board_bcm21664.c
> index f0521cc..82ad568 100644
> --- a/arch/arm/mach-bcm/board_bcm21664.c
> +++ b/arch/arm/mach-bcm/board_bcm21664.c
> @@ -60,8 +60,7 @@ static void bcm21664_restart(enum reboot_mode mode, const char *cmd)
>
> static void __init bcm21664_init(void)
> {
> - of_platform_populate(NULL, of_default_bus_match_table, NULL,
> - &platform_bus);
> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> kona_l2_cache_init();
> }
>
> diff --git a/arch/arm/mach-bcm/board_bcm281xx.c b/arch/arm/mach-bcm/board_bcm281xx.c
> index 1ac59fc..2e367bd 100644
> --- a/arch/arm/mach-bcm/board_bcm281xx.c
> +++ b/arch/arm/mach-bcm/board_bcm281xx.c
> @@ -58,8 +58,7 @@ static void bcm281xx_restart(enum reboot_mode mode, const char *cmd)
>
> static void __init bcm281xx_init(void)
> {
> - of_platform_populate(NULL, of_default_bus_match_table, NULL,
> - &platform_bus);
> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> kona_l2_cache_init();
> }
>
> diff --git a/arch/arm/mach-clps711x/board-edb7211.c b/arch/arm/mach-clps711x/board-edb7211.c
> index f9828f8..6144fb5 100644
> --- a/arch/arm/mach-clps711x/board-edb7211.c
> +++ b/arch/arm/mach-clps711x/board-edb7211.c
> @@ -158,16 +158,16 @@ static void __init edb7211_init_late(void)
> gpio_request_array(edb7211_gpios, ARRAY_SIZE(edb7211_gpios));
>
> platform_device_register(&edb7211_flash_pdev);
> - platform_device_register_data(&platform_bus, "platform-lcd", 0,
> + platform_device_register_data(NULL, "platform-lcd", 0,
> &edb7211_lcd_power_pdata,
> sizeof(edb7211_lcd_power_pdata));
> - platform_device_register_data(&platform_bus, "generic-bl", 0,
> + platform_device_register_data(NULL, "generic-bl", 0,
> &edb7211_lcd_backlight_pdata,
> sizeof(edb7211_lcd_backlight_pdata));
> platform_device_register_simple("video-clps711x", 0, NULL, 0);
> platform_device_register_simple("cs89x0", 0, edb7211_cs8900_resource,
> ARRAY_SIZE(edb7211_cs8900_resource));
> - platform_device_register_data(&platform_bus, "i2c-gpio", 0,
> + platform_device_register_data(NULL, "i2c-gpio", 0,
> &edb7211_i2c_pdata,
> sizeof(edb7211_i2c_pdata));
> }
> diff --git a/arch/arm/mach-clps711x/board-p720t.c b/arch/arm/mach-clps711x/board-p720t.c
> index 0cf0e51..96bcc76 100644
> --- a/arch/arm/mach-clps711x/board-p720t.c
> +++ b/arch/arm/mach-clps711x/board-p720t.c
> @@ -348,14 +348,14 @@ static void __init p720t_init_late(void)
> {
> WARN_ON(gpio_request_array(p720t_gpios, ARRAY_SIZE(p720t_gpios)));
>
> - platform_device_register_data(&platform_bus, "platform-lcd", 0,
> + platform_device_register_data(NULL, "platform-lcd", 0,
> &p720t_lcd_power_pdata,
> sizeof(p720t_lcd_power_pdata));
> - platform_device_register_data(&platform_bus, "generic-bl", 0,
> + platform_device_register_data(NULL, "generic-bl", 0,
> &p720t_lcd_backlight_pdata,
> sizeof(p720t_lcd_backlight_pdata));
> platform_device_register_simple("video-clps711x", 0, NULL, 0);
> - platform_device_register_data(&platform_bus, "leds-gpio", 0,
> + platform_device_register_data(NULL, "leds-gpio", 0,
> &p720t_gpio_led_pdata,
> sizeof(p720t_gpio_led_pdata));
> }
> diff --git a/arch/arm/mach-imx/devices/devices.c b/arch/arm/mach-imx/devices/devices.c
> index 1b4366a..48c3817 100644
> --- a/arch/arm/mach-imx/devices/devices.c
> +++ b/arch/arm/mach-imx/devices/devices.c
> @@ -24,12 +24,12 @@
>
> struct device mxc_aips_bus = {
> .init_name = "mxc_aips",
> - .parent = &platform_bus,
> + .parent = &platform_bus.dev,
> };
>
> struct device mxc_ahb_bus = {
> .init_name = "mxc_ahb",
> - .parent = &platform_bus,
> + .parent = &platform_bus.dev,
> };
>
> int __init mxc_device_init(void)
> diff --git a/arch/arm/mach-imx/mach-mx27ads.c b/arch/arm/mach-imx/mach-mx27ads.c
> index 2f834ce..eb1c347 100644
> --- a/arch/arm/mach-imx/mach-mx27ads.c
> +++ b/arch/arm/mach-imx/mach-mx27ads.c
> @@ -245,7 +245,7 @@ static void __init mx27ads_regulator_init(void)
> vchip->set = vgpio_set;
> gpiochip_add(vchip);
>
> - platform_device_register_data(&platform_bus, "reg-fixed-voltage",
> + platform_device_register_data(NULL, "reg-fixed-voltage",
> PLATFORM_DEVID_AUTO,
> &mx27ads_lcd_regulator_pdata,
> sizeof(mx27ads_lcd_regulator_pdata));
> diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
> index fe071a9..7ab99a4 100644
> --- a/arch/arm/mach-shmobile/board-ape6evm.c
> +++ b/arch/arm/mach-shmobile/board-ape6evm.c
> @@ -248,29 +248,29 @@ static void __init ape6evm_add_standard_devices(void)
>
> regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
>
> - platform_device_register_resndata(&platform_bus, "smsc911x", -1,
> + platform_device_register_resndata(NULL, "smsc911x", -1,
> lan9220_res, ARRAY_SIZE(lan9220_res),
> &lan9220_data, sizeof(lan9220_data));
>
> regulator_register_always_on(1, "MMC0 Vcc", vcc_mmc0_consumers,
> ARRAY_SIZE(vcc_mmc0_consumers), 2800000);
> - platform_device_register_resndata(&platform_bus, "sh_mmcif", 0,
> + platform_device_register_resndata(NULL, "sh_mmcif", 0,
> mmcif0_resources, ARRAY_SIZE(mmcif0_resources),
> &mmcif0_pdata, sizeof(mmcif0_pdata));
> - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 2,
> + platform_device_register_data(NULL, "reg-fixed-voltage", 2,
> &vcc_sdhi0_info, sizeof(vcc_sdhi0_info));
> - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0,
> + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 0,
> sdhi0_resources, ARRAY_SIZE(sdhi0_resources),
> &sdhi0_pdata, sizeof(sdhi0_pdata));
> regulator_register_always_on(3, "SDHI1 Vcc", vcc_sdhi1_consumers,
> ARRAY_SIZE(vcc_sdhi1_consumers), 3300000);
> - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 1,
> + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 1,
> sdhi1_resources, ARRAY_SIZE(sdhi1_resources),
> &sdhi1_pdata, sizeof(sdhi1_pdata));
> - platform_device_register_data(&platform_bus, "gpio-keys", -1,
> + platform_device_register_data(NULL, "gpio-keys", -1,
> &ape6evm_keys_pdata,
> sizeof(ape6evm_keys_pdata));
> - platform_device_register_data(&platform_bus, "leds-gpio", -1,
> + platform_device_register_data(NULL, "leds-gpio", -1,
> &ape6evm_leds_pdata,
> sizeof(ape6evm_leds_pdata));
> }
> diff --git a/arch/arm/mach-shmobile/board-bockw.c b/arch/arm/mach-shmobile/board-bockw.c
> index f444be2..3ec82a4 100644
> --- a/arch/arm/mach-shmobile/board-bockw.c
> +++ b/arch/arm/mach-shmobile/board-bockw.c
> @@ -177,7 +177,7 @@ static struct renesas_usbhs_platform_info usbhs_info __initdata = {
> #define USB1_DEVICE "renesas_usbhs"
> #define ADD_USB_FUNC_DEVICE_IF_POSSIBLE() \
> platform_device_register_resndata( \
> - &platform_bus, "renesas_usbhs", -1, \
> + NULL, "renesas_usbhs", -1, \
> usbhsf_resources, \
> ARRAY_SIZE(usbhsf_resources), \
> &usbhs_info, sizeof(struct renesas_usbhs_platform_info))
> @@ -236,7 +236,6 @@ static struct sh_eth_plat_data ether_platform_data __initdata = {
> };
>
> static struct platform_device_info ether_info __initdata = {
> - .parent = &platform_bus,
> .name = "r8a777x-ether",
> .id = -1,
> .res = ether_resources,
> @@ -322,7 +321,6 @@ static struct resource vin##idx##_resources[] __initdata = { \
> }; \
> \
> static struct platform_device_info vin##idx##_info __initdata = { \
> - .parent = &platform_bus, \
> .name = "r8a7778-vin", \
> .id = idx, \
> .res = vin##idx##_resources, \
> @@ -621,10 +619,10 @@ static void __init bockw_init(void)
> /* VIN1 has a pin conflict with Ether */
> if (!IS_ENABLED(CONFIG_SH_ETH))
> platform_device_register_full(&vin1_info);
> - platform_device_register_data(&platform_bus, "soc-camera-pdrv", 0,
> + platform_device_register_data(NULL, "soc-camera-pdrv", 0,
> &iclink0_ml86v7667,
> sizeof(iclink0_ml86v7667));
> - platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1,
> + platform_device_register_data(NULL, "soc-camera-pdrv", 1,
> &iclink1_ml86v7667,
> sizeof(iclink1_ml86v7667));
>
> @@ -637,12 +635,12 @@ static void __init bockw_init(void)
> r8a7778_pinmux_init();
>
> platform_device_register_resndata(
> - &platform_bus, "sh_mmcif", -1,
> + NULL, "sh_mmcif", -1,
> mmc_resources, ARRAY_SIZE(mmc_resources),
> &sh_mmcif_plat, sizeof(struct sh_mmcif_plat_data));
>
> platform_device_register_resndata(
> - &platform_bus, "rcar_usb_phy", -1,
> + NULL, "rcar_usb_phy", -1,
> usb_phy_resources,
> ARRAY_SIZE(usb_phy_resources),
> &usb_phy_platform_data,
> @@ -668,7 +666,7 @@ static void __init bockw_init(void)
> iowrite16(val, fpga + IRQ0MR);
>
> platform_device_register_resndata(
> - &platform_bus, "smsc911x", -1,
> + NULL, "smsc911x", -1,
> smsc911x_resources, ARRAY_SIZE(smsc911x_resources),
> &smsc911x_data, sizeof(smsc911x_data));
> }
> @@ -685,7 +683,7 @@ static void __init bockw_init(void)
> iounmap(base);
>
> platform_device_register_resndata(
> - &platform_bus, "sh_mobile_sdhi", 0,
> + NULL, "sh_mobile_sdhi", 0,
> sdhi0_resources, ARRAY_SIZE(sdhi0_resources),
> &sdhi0_info, sizeof(struct sh_mobile_sdhi_info));
> }
> @@ -700,7 +698,7 @@ static void __init bockw_init(void)
> "ak4554-adc-dac", 1, NULL, 0);
>
> pdev = platform_device_register_resndata(
> - &platform_bus, "rcar_sound", -1,
> + NULL, "rcar_sound", -1,
> rsnd_resources, ARRAY_SIZE(rsnd_resources),
> &rsnd_info, sizeof(rsnd_info));
>
> @@ -710,7 +708,6 @@ static void __init bockw_init(void)
>
> for (i = 0; i < ARRAY_SIZE(rsnd_card_info); i++) {
> struct platform_device_info cardinfo = {
> - .parent = &platform_bus,
> .name = "asoc-simple-card",
> .id = i,
> .data = &rsnd_card_info[i],
> diff --git a/arch/arm/mach-shmobile/board-genmai.c b/arch/arm/mach-shmobile/board-genmai.c
> index c94201e..37184ff 100644
> --- a/arch/arm/mach-shmobile/board-genmai.c
> +++ b/arch/arm/mach-shmobile/board-genmai.c
> @@ -46,7 +46,6 @@ static const struct resource ether_resources[] __initconst = {
> };
>
> static const struct platform_device_info ether_info __initconst = {
> - .parent = &platform_bus,
> .name = "r7s72100-ether",
> .id = -1,
> .res = ether_resources,
> @@ -76,7 +75,7 @@ static const struct rspi_plat_data rspi_pdata __initconst = {
> };
>
> #define r7s72100_register_rspi(idx) \
> - platform_device_register_resndata(&platform_bus, "rspi-rz", idx, \
> + platform_device_register_resndata(NULL, "rspi-rz", idx, \
> rspi##idx##_resources, \
> ARRAY_SIZE(rspi##idx##_resources), \
> &rspi_pdata, sizeof(rspi_pdata))
> @@ -118,7 +117,7 @@ R7S72100_SCIF(6, 0xe800a000, gic_iid(245));
> R7S72100_SCIF(7, 0xe800a800, gic_iid(249));
>
> #define r7s72100_register_scif(index) \
> - platform_device_register_resndata(&platform_bus, "sh-sci", index, \
> + platform_device_register_resndata(NULL, "sh-sci", index, \
> scif##index##_resources, \
> ARRAY_SIZE(scif##index##_resources), \
> &scif##index##_platform_data, \
> diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
> index c6c6889..d3aa6ae 100644
> --- a/arch/arm/mach-shmobile/board-koelsch.c
> +++ b/arch/arm/mach-shmobile/board-koelsch.c
> @@ -118,7 +118,6 @@ static const struct resource ether_resources[] __initconst = {
> };
>
> static const struct platform_device_info ether_info __initconst = {
> - .parent = &platform_bus,
> .name = "r8a7791-ether",
> .id = -1,
> .res = ether_resources,
> @@ -230,7 +229,6 @@ static const struct resource sata0_resources[] __initconst = {
> };
>
> static const struct platform_device_info sata0_info __initconst = {
> - .parent = &platform_bus,
> .name = "sata-r8a7791",
> .id = 0,
> .res = sata0_resources,
> @@ -439,13 +437,13 @@ static void __init koelsch_add_standard_devices(void)
> r8a7791_pinmux_init();
> r8a7791_add_standard_devices();
> platform_device_register_full(ðer_info);
> - platform_device_register_data(&platform_bus, "leds-gpio", -1,
> + platform_device_register_data(NULL, "leds-gpio", -1,
> &koelsch_leds_pdata,
> sizeof(koelsch_leds_pdata));
> - platform_device_register_data(&platform_bus, "gpio-keys", -1,
> + platform_device_register_data(NULL, "gpio-keys", -1,
> &koelsch_keys_pdata,
> sizeof(koelsch_keys_pdata));
> - platform_device_register_resndata(&platform_bus, "qspi", 0,
> + platform_device_register_resndata(NULL, "qspi", 0,
> qspi_resources,
> ARRAY_SIZE(qspi_resources),
> &qspi_pdata, sizeof(qspi_pdata));
> @@ -460,28 +458,28 @@ static void __init koelsch_add_standard_devices(void)
> koelsch_add_i2c(4);
> koelsch_add_i2c(5);
>
> - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 0,
> + platform_device_register_data(NULL, "reg-fixed-voltage", 0,
> &vcc_sdhi0_info, sizeof(struct fixed_voltage_config));
> - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 1,
> + platform_device_register_data(NULL, "reg-fixed-voltage", 1,
> &vcc_sdhi1_info, sizeof(struct fixed_voltage_config));
> - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 2,
> + platform_device_register_data(NULL, "reg-fixed-voltage", 2,
> &vcc_sdhi2_info, sizeof(struct fixed_voltage_config));
> - platform_device_register_data(&platform_bus, "gpio-regulator", 0,
> + platform_device_register_data(NULL, "gpio-regulator", 0,
> &vccq_sdhi0_info, sizeof(struct gpio_regulator_config));
> - platform_device_register_data(&platform_bus, "gpio-regulator", 1,
> + platform_device_register_data(NULL, "gpio-regulator", 1,
> &vccq_sdhi1_info, sizeof(struct gpio_regulator_config));
> - platform_device_register_data(&platform_bus, "gpio-regulator", 2,
> + platform_device_register_data(NULL, "gpio-regulator", 2,
> &vccq_sdhi2_info, sizeof(struct gpio_regulator_config));
>
> - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0,
> + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 0,
> sdhi0_resources, ARRAY_SIZE(sdhi0_resources),
> &sdhi0_info, sizeof(struct sh_mobile_sdhi_info));
>
> - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 1,
> + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 1,
> sdhi1_resources, ARRAY_SIZE(sdhi1_resources),
> &sdhi1_info, sizeof(struct sh_mobile_sdhi_info));
>
> - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 2,
> + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 2,
> sdhi2_resources, ARRAY_SIZE(sdhi2_resources),
> &sdhi2_info, sizeof(struct sh_mobile_sdhi_info));
>
> diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
> index f8b1e05..d182961 100644
> --- a/arch/arm/mach-shmobile/board-lager.c
> +++ b/arch/arm/mach-shmobile/board-lager.c
> @@ -277,7 +277,6 @@ static const struct resource ether_resources[] __initconst = {
> };
>
> static const struct platform_device_info ether_info __initconst = {
> - .parent = &platform_bus,
> .name = "r8a7790-ether",
> .id = -1,
> .res = ether_resources,
> @@ -354,7 +353,6 @@ static void __init lager_add_vin_device(unsigned idx,
> struct rcar_vin_platform_data *pdata)
> {
> struct platform_device_info vin_info = {
> - .parent = &platform_bus,
> .name = "r8a7790-vin",
> .id = idx,
> .res = &vin_resources[idx * 2],
> @@ -391,7 +389,7 @@ LAGER_CAMERA(1, "adv7180", 0x20, NULL, RCAR_VIN_BT656);
>
> static void __init lager_add_camera1_device(void)
> {
> - platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1,
> + platform_device_register_data(NULL, "soc-camera-pdrv", 1,
> &cam1_link, sizeof(cam1_link));
> lager_add_vin_device(1, &vin1_pdata);
> }
> @@ -403,7 +401,6 @@ static const struct resource sata1_resources[] __initconst = {
> };
>
> static const struct platform_device_info sata1_info __initconst = {
> - .parent = &platform_bus,
> .name = "sata-r8a7790",
> .id = 1,
> .res = sata1_resources,
> @@ -533,7 +530,7 @@ static struct usbhs_private usbhs_priv __initdata = {
> static void __init lager_register_usbhs(void)
> {
> usb_bind_phy("renesas_usbhs", 0, "usb_phy_rcar_gen2");
> - platform_device_register_resndata(&platform_bus,
> + platform_device_register_resndata(NULL,
> "renesas_usbhs", -1,
> usbhs_resources,
> ARRAY_SIZE(usbhs_resources),
> @@ -608,7 +605,6 @@ static struct asoc_simple_card_info rsnd_card_info = {
> static void __init lager_add_rsnd_device(void)
> {
> struct platform_device_info cardinfo = {
> - .parent = &platform_bus,
> .name = "asoc-simple-card",
> .id = -1,
> .data = &rsnd_card_info,
> @@ -620,7 +616,7 @@ static void __init lager_add_rsnd_device(void)
> ARRAY_SIZE(i2c2_devices));
>
> platform_device_register_resndata(
> - &platform_bus, "rcar_sound", -1,
> + NULL, "rcar_sound", -1,
> rsnd_resources, ARRAY_SIZE(rsnd_resources),
> &rsnd_info, sizeof(rsnd_info));
>
> @@ -663,7 +659,6 @@ static const struct resource pci1_resources[] __initconst = {
> };
>
> static const struct platform_device_info pci1_info __initconst = {
> - .parent = &platform_bus,
> .name = "pci-rcar-gen2",
> .id = 1,
> .res = pci1_resources,
> @@ -684,7 +679,6 @@ static const struct resource pci2_resources[] __initconst = {
> };
>
> static const struct platform_device_info pci2_info __initconst = {
> - .parent = &platform_bus,
> .name = "pci-rcar-gen2",
> .id = 2,
> .res = pci2_resources,
> @@ -795,16 +789,16 @@ static void __init lager_add_standard_devices(void)
> r8a7790_pinmux_init();
>
> r8a7790_add_standard_devices();
> - platform_device_register_data(&platform_bus, "leds-gpio", -1,
> + platform_device_register_data(NULL, "leds-gpio", -1,
> &lager_leds_pdata,
> sizeof(lager_leds_pdata));
> - platform_device_register_data(&platform_bus, "gpio-keys", -1,
> + platform_device_register_data(NULL, "gpio-keys", -1,
> &lager_keys_pdata,
> sizeof(lager_keys_pdata));
> regulator_register_always_on(fixed_regulator_idx++,
> "fixed-3.3V", fixed3v3_power_consumers,
> ARRAY_SIZE(fixed3v3_power_consumers), 3300000);
> - platform_device_register_resndata(&platform_bus, "sh_mmcif", 1,
> + platform_device_register_resndata(NULL, "sh_mmcif", 1,
> mmcif1_resources, ARRAY_SIZE(mmcif1_resources),
> &mmcif1_pdata, sizeof(mmcif1_pdata));
>
> @@ -812,27 +806,27 @@ static void __init lager_add_standard_devices(void)
>
> lager_add_du_device();
>
> - platform_device_register_resndata(&platform_bus, "qspi", 0,
> + platform_device_register_resndata(NULL, "qspi", 0,
> qspi_resources,
> ARRAY_SIZE(qspi_resources),
> &qspi_pdata, sizeof(qspi_pdata));
> spi_register_board_info(spi_info, ARRAY_SIZE(spi_info));
>
> - platform_device_register_data(&platform_bus, "reg-fixed-voltage", fixed_regulator_idx++,
> + platform_device_register_data(NULL, "reg-fixed-voltage", fixed_regulator_idx++,
> &vcc_sdhi0_info, sizeof(struct fixed_voltage_config));
> - platform_device_register_data(&platform_bus, "reg-fixed-voltage", fixed_regulator_idx++,
> + platform_device_register_data(NULL, "reg-fixed-voltage", fixed_regulator_idx++,
> &vcc_sdhi2_info, sizeof(struct fixed_voltage_config));
>
> - platform_device_register_data(&platform_bus, "gpio-regulator", gpio_regulator_idx++,
> + platform_device_register_data(NULL, "gpio-regulator", gpio_regulator_idx++,
> &vccq_sdhi0_info, sizeof(struct gpio_regulator_config));
> - platform_device_register_data(&platform_bus, "gpio-regulator", gpio_regulator_idx++,
> + platform_device_register_data(NULL, "gpio-regulator", gpio_regulator_idx++,
> &vccq_sdhi2_info, sizeof(struct gpio_regulator_config));
>
> lager_add_camera1_device();
>
> platform_device_register_full(&sata1_info);
>
> - platform_device_register_resndata(&platform_bus, "usb_phy_rcar_gen2",
> + platform_device_register_resndata(NULL, "usb_phy_rcar_gen2",
> -1, usbhs_phy_resources,
> ARRAY_SIZE(usbhs_phy_resources),
> &usbhs_phy_pdata,
> @@ -843,10 +837,10 @@ static void __init lager_add_standard_devices(void)
>
> lager_add_rsnd_device();
>
> - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0,
> + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 0,
> sdhi0_resources, ARRAY_SIZE(sdhi0_resources),
> &sdhi0_info, sizeof(struct sh_mobile_sdhi_info));
> - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 2,
> + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 2,
> sdhi2_resources, ARRAY_SIZE(sdhi2_resources),
> &sdhi2_info, sizeof(struct sh_mobile_sdhi_info));
> }
> diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c
> index d832a44..6ed324c 100644
> --- a/arch/arm/mach-shmobile/board-marzen.c
> +++ b/arch/arm/mach-shmobile/board-marzen.c
> @@ -272,7 +272,6 @@ static struct resource vin##idx##_resources[] __initdata = { \
> }; \
> \
> static struct platform_device_info vin##idx##_info __initdata = { \
> - .parent = &platform_bus, \
> .name = "r8a7779-vin", \
> .id = idx, \
> .res = vin##idx##_resources, \
> diff --git a/arch/arm/mach-shmobile/setup-r7s72100.c b/arch/arm/mach-shmobile/setup-r7s72100.c
> index 412e179..3885a59 100644
> --- a/arch/arm/mach-shmobile/setup-r7s72100.c
> +++ b/arch/arm/mach-shmobile/setup-r7s72100.c
> @@ -33,7 +33,7 @@ static struct resource mtu2_resources[] __initdata = {
> };
>
> #define r7s72100_register_mtu2() \
> - platform_device_register_resndata(&platform_bus, "sh-mtu2", \
> + platform_device_register_resndata(NULL, "sh-mtu2", \
> -1, mtu2_resources, \
> ARRAY_SIZE(mtu2_resources), \
> NULL, 0)
> diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c
> index 9333770..aaaaf6e 100644
> --- a/arch/arm/mach-shmobile/setup-r8a73a4.c
> +++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
> @@ -68,7 +68,7 @@ R8A73A4_SCIFB(4, 0xe6ce0000, gic_spi(150)); /* SCIFB2 */
> R8A73A4_SCIFB(5, 0xe6cf0000, gic_spi(151)); /* SCIFB3 */
>
> #define r8a73a4_register_scif(index) \
> - platform_device_register_resndata(&platform_bus, "sh-sci", index, \
> + platform_device_register_resndata(NULL, "sh-sci", index, \
> scif##index##_resources, \
> ARRAY_SIZE(scif##index##_resources), \
> &scif##index##_platform_data, \
> @@ -149,7 +149,7 @@ static const struct resource irqc1_resources[] = {
> };
>
> #define r8a73a4_register_irqc(idx) \
> - platform_device_register_resndata(&platform_bus, "renesas_irqc", \
> + platform_device_register_resndata(NULL, "renesas_irqc", \
> idx, irqc##idx##_resources, \
> ARRAY_SIZE(irqc##idx##_resources), \
> &irqc##idx##_data, \
> @@ -179,7 +179,7 @@ static struct resource cmt1_resources[] = {
> };
>
> #define r8a7790_register_cmt(idx) \
> - platform_device_register_resndata(&platform_bus, "sh-cmt-48-gen2", \
> + platform_device_register_resndata(NULL, "sh-cmt-48-gen2", \
> idx, cmt##idx##_resources, \
> ARRAY_SIZE(cmt##idx##_resources), \
> &cmt##idx##_platform_data, \
> @@ -280,7 +280,7 @@ static struct resource dma_resources[] = {
> };
>
> #define r8a73a4_register_dmac() \
> - platform_device_register_resndata(&platform_bus, "sh-dma-engine", 0, \
> + platform_device_register_resndata(NULL, "sh-dma-engine", 0, \
> dma_resources, ARRAY_SIZE(dma_resources), \
> &dma_pdata, sizeof(dma_pdata))
>
> diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c
> index d311ef9..5de7b33 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7778.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7778.c
> @@ -64,7 +64,7 @@ R8A7778_SCIF(4, 0xffe44000, gic_iid(0x6a));
> R8A7778_SCIF(5, 0xffe45000, gic_iid(0x6b));
>
> #define r8a7778_register_scif(index) \
> - platform_device_register_resndata(&platform_bus, "sh-sci", index, \
> + platform_device_register_resndata(NULL, "sh-sci", index, \
> scif##index##_resources, \
> ARRAY_SIZE(scif##index##_resources), \
> &scif##index##_platform_data, \
> @@ -84,7 +84,7 @@ static struct resource sh_tmu0_resources[] = {
>
> #define r8a7778_register_tmu(idx) \
> platform_device_register_resndata( \
> - &platform_bus, "sh-tmu", idx, \
> + NULL, "sh-tmu", idx, \
> sh_tmu##idx##_resources, \
> ARRAY_SIZE(sh_tmu##idx##_resources), \
> &sh_tmu##idx##_platform_data, \
> @@ -173,7 +173,6 @@ static struct resource ohci_resources[] __initdata = {
>
> #define USB_PLATFORM_INFO(hci) \
> static struct platform_device_info hci##_info __initdata = { \
> - .parent = &platform_bus, \
> .name = #hci "-platform", \
> .id = -1, \
> .res = hci##_resources, \
> @@ -212,7 +211,7 @@ R8A7778_GPIO(4);
>
> #define r8a7778_register_gpio(idx) \
> platform_device_register_resndata( \
> - &platform_bus, "gpio_rcar", idx, \
> + NULL, "gpio_rcar", idx, \
> r8a7778_gpio##idx##_resources, \
> ARRAY_SIZE(r8a7778_gpio##idx##_resources), \
> &r8a7778_gpio##idx##_platform_data, \
> @@ -496,8 +495,8 @@ static struct resource hpb_dmae_resources[] __initdata = {
>
> static void __init r8a7778_register_hpb_dmae(void)
> {
> - platform_device_register_resndata(&platform_bus, "hpb-dma-engine", -1,
> - hpb_dmae_resources,
> + platform_device_register_resndata(NULL, "hpb-dma-engine",
> + -1, hpb_dmae_resources,
> ARRAY_SIZE(hpb_dmae_resources),
> &dma_platform_data,
> sizeof(dma_platform_data));
> @@ -565,7 +564,7 @@ void __init r8a7778_init_irq_extpin(int irlm)
> r8a7778_init_irq_extpin_dt(irlm);
> if (irlm)
> platform_device_register_resndata(
> - &platform_bus, "renesas_intc_irqpin", -1,
> + NULL, "renesas_intc_irqpin", -1,
> irqpin_resources, ARRAY_SIZE(irqpin_resources),
> &irqpin_platform_data, sizeof(irqpin_platform_data));
> }
> diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c
> index aba4ed6..9c79182 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7779.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7779.c
> @@ -123,7 +123,7 @@ void __init r8a7779_init_irq_extpin(int irlm)
> r8a7779_init_irq_extpin_dt(irlm);
> if (irlm)
> platform_device_register_resndata(
> - &platform_bus, "renesas_intc_irqpin", -1,
> + NULL, "renesas_intc_irqpin", -1,
> irqpin0_resources, ARRAY_SIZE(irqpin0_resources),
> &irqpin0_platform_data, sizeof(irqpin0_platform_data));
> }
> @@ -632,8 +632,8 @@ static struct resource hpb_dmae_resources[] __initdata = {
>
> static void __init r8a7779_register_hpb_dmae(void)
> {
> - platform_device_register_resndata(&platform_bus, "hpb-dma-engine", -1,
> - hpb_dmae_resources,
> + platform_device_register_resndata(NULL, "hpb-dma-engine",
> + -1, hpb_dmae_resources,
> ARRAY_SIZE(hpb_dmae_resources),
> &dma_platform_data,
> sizeof(dma_platform_data));
> diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
> index 6bd08b1..10e6768 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7790.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7790.c
> @@ -113,7 +113,7 @@ static struct resource r8a7790_audio_dmac_resources[] = {
>
> #define r8a7790_register_audio_dmac(id) \
> platform_device_register_resndata( \
> - &platform_bus, "sh-dma-engine", id, \
> + NULL, "sh-dma-engine", id, \
> &r8a7790_audio_dmac_resources[id * 3], 3, \
> &r8a7790_audio_dmac_platform_data, \
> sizeof(r8a7790_audio_dmac_platform_data))
> @@ -149,7 +149,7 @@ R8A7790_GPIO(4);
> R8A7790_GPIO(5);
>
> #define r8a7790_register_gpio(idx) \
> - platform_device_register_resndata(&platform_bus, "gpio_rcar", idx, \
> + platform_device_register_resndata(NULL, "gpio_rcar", idx, \
> r8a7790_gpio##idx##_resources, \
> ARRAY_SIZE(r8a7790_gpio##idx##_resources), \
> &r8a7790_gpio##idx##_platform_data, \
> @@ -227,7 +227,7 @@ R8A7790_HSCIF(8, 0xe62c0000, gic_spi(154)); /* HSCIF0 */
> R8A7790_HSCIF(9, 0xe62c8000, gic_spi(155)); /* HSCIF1 */
>
> #define r8a7790_register_scif(index) \
> - platform_device_register_resndata(&platform_bus, "sh-sci", index, \
> + platform_device_register_resndata(NULL, "sh-sci", index, \
> scif##index##_resources, \
> ARRAY_SIZE(scif##index##_resources), \
> &scif##index##_platform_data, \
> @@ -246,7 +246,7 @@ static const struct resource irqc0_resources[] __initconst = {
> };
>
> #define r8a7790_register_irqc(idx) \
> - platform_device_register_resndata(&platform_bus, "renesas_irqc", \
> + platform_device_register_resndata(NULL, "renesas_irqc", \
> idx, irqc##idx##_resources, \
> ARRAY_SIZE(irqc##idx##_resources), \
> &irqc##idx##_data, \
> @@ -273,7 +273,7 @@ static struct resource cmt0_resources[] = {
> };
>
> #define r8a7790_register_cmt(idx) \
> - platform_device_register_resndata(&platform_bus, "sh-cmt-48-gen2", \
> + platform_device_register_resndata(NULL, "sh-cmt-48-gen2", \
> idx, cmt##idx##_resources, \
> ARRAY_SIZE(cmt##idx##_resources), \
> &cmt##idx##_platform_data, \
> diff --git a/arch/arm/mach-shmobile/setup-r8a7791.c b/arch/arm/mach-shmobile/setup-r8a7791.c
> index 04a96dd..fd54437 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7791.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7791.c
> @@ -65,7 +65,7 @@ R8A7791_GPIO(6, 0xe6055400, 32);
> R8A7791_GPIO(7, 0xe6055800, 26);
>
> #define r8a7791_register_gpio(idx) \
> - platform_device_register_resndata(&platform_bus, "gpio_rcar", idx, \
> + platform_device_register_resndata(NULL, "gpio_rcar", idx, \
> r8a7791_gpio##idx##_resources, \
> ARRAY_SIZE(r8a7791_gpio##idx##_resources), \
> &r8a7791_gpio##idx##_platform_data, \
> @@ -122,7 +122,7 @@ R8A7791_SCIFA(13, 0xe6c78000, gic_spi(30)); /* SCIFA4 */
> R8A7791_SCIFA(14, 0xe6c80000, gic_spi(31)); /* SCIFA5 */
>
> #define r8a7791_register_scif(index) \
> - platform_device_register_resndata(&platform_bus, "sh-sci", index, \
> + platform_device_register_resndata(NULL, "sh-sci", index, \
> scif##index##_resources, \
> ARRAY_SIZE(scif##index##_resources), \
> &scif##index##_platform_data, \
> @@ -138,7 +138,7 @@ static struct resource cmt0_resources[] = {
> };
>
> #define r8a7791_register_cmt(idx) \
> - platform_device_register_resndata(&platform_bus, "sh-cmt-48-gen2", \
> + platform_device_register_resndata(NULL, "sh-cmt-48-gen2", \
> idx, cmt##idx##_resources, \
> ARRAY_SIZE(cmt##idx##_resources), \
> &cmt##idx##_platform_data, \
> @@ -163,7 +163,7 @@ static struct resource irqc0_resources[] = {
> };
>
> #define r8a7791_register_irqc(idx) \
> - platform_device_register_resndata(&platform_bus, "renesas_irqc", \
> + platform_device_register_resndata(NULL, "renesas_irqc", \
> idx, irqc##idx##_resources, \
> ARRAY_SIZE(irqc##idx##_resources), \
> &irqc##idx##_data, \
> diff --git a/arch/unicore32/kernel/puv3-core.c b/arch/unicore32/kernel/puv3-core.c
> index 254adee..438dd2e 100644
> --- a/arch/unicore32/kernel/puv3-core.c
> +++ b/arch/unicore32/kernel/puv3-core.c
> @@ -272,7 +272,7 @@ void __init puv3_core_init(void)
> platform_device_register_simple("PKUnity-v3-UART", 1,
> puv3_uart1_resources, ARRAY_SIZE(puv3_uart1_resources));
> platform_device_register_simple("PKUnity-v3-AC97", -1, NULL, 0);
> - platform_device_register_resndata(&platform_bus, "musb_hdrc", -1,
> + platform_device_register_resndata(NULL, "musb_hdrc", -1,
> puv3_usb_resources, ARRAY_SIZE(puv3_usb_resources),
> &puv3_usb_plat, sizeof(puv3_usb_plat));
> }
> diff --git a/arch/unicore32/kernel/puv3-nb0916.c b/arch/unicore32/kernel/puv3-nb0916.c
> index 0c6618e..46ebfdc 100644
> --- a/arch/unicore32/kernel/puv3-nb0916.c
> +++ b/arch/unicore32/kernel/puv3-nb0916.c
> @@ -112,13 +112,13 @@ int __init mach_nb0916_init(void)
> platform_device_register_simple("PKUnity-v3-I2C", -1,
> puv3_i2c_resources, ARRAY_SIZE(puv3_i2c_resources));
>
> - platform_device_register_data(&platform_bus, "pwm-backlight", -1,
> + platform_device_register_data(NULL, "pwm-backlight", -1,
> &nb0916_backlight_data, sizeof(nb0916_backlight_data));
>
> - platform_device_register_data(&platform_bus, "gpio-keys", -1,
> + platform_device_register_data(NULL, "gpio-keys", -1,
> &nb0916_gpio_button_data, sizeof(nb0916_gpio_button_data));
>
> - platform_device_register_resndata(&platform_bus, "physmap-flash", -1,
> + platform_device_register_resndata(NULL, "physmap-flash", -1,
> &physmap_flash_resource, 1,
> &physmap_flash_data, sizeof(physmap_flash_data));
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index eee48c4..f272603 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -30,8 +30,8 @@
> /* For automatically allocated device IDs */
> static DEFINE_IDA(platform_devid_ida);
>
> -struct device platform_bus = {
> - .init_name = "platform",
> +struct platform_device platform_bus = {
> + .name = "platform",
> };
> EXPORT_SYMBOL_GPL(platform_bus);
>
> @@ -300,7 +300,7 @@ int platform_device_add(struct platform_device *pdev)
> return -EINVAL;
>
> if (!pdev->dev.parent)
> - pdev->dev.parent = &platform_bus;
> + pdev->dev.parent = &platform_bus.dev;
>
> pdev->dev.bus = &platform_bus_type;
>
> @@ -946,12 +946,18 @@ int __init platform_bus_init(void)
>
> early_platform_cleanup();
>
> - error = device_register(&platform_bus);
> + dev_set_name(&platform_bus.dev, "%s", platform_bus.name);
> + error = device_register(&platform_bus.dev);
> if (error)
> return error;
> error = bus_register(&platform_bus_type);
> - if (error)
> - device_unregister(&platform_bus);
> + if (!error) {
> + platform_bus.dev.of_node = of_allnodes;
This breaks all non-OF platforms:
drivers/base/platform.c: In function 'platform_bus_init':
drivers/base/platform.c:955:30: error: 'of_allnodes' undeclared (first
use in this function)
platform_bus.dev.of_node = of_allnodes;
-Olof
^ permalink raw reply
* [PATCH v3 0/8] Two-phase seccomp and x86 tracing changes
From: Kees Cook @ 2014-07-22 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1405992946.git.luto@amacapital.net>
On Mon, Jul 21, 2014 at 6:49 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> [applies on jmorris's security-next tree]
>
> This is both a cleanup and a speedup. It reduces overhead due to
> installing a trivial seccomp filter by 87%. The speedup comes from
> avoiding the full syscall tracing mechanism for filters that don't
> return SECCOMP_RET_TRACE.
>
> This series works by splitting the seccomp hooks into two phases.
> The first phase evaluates the filter; it can skip syscalls, allow
> them, kill the calling task, or pass a u32 to the second phase. The
> second phase requires a full tracing context, and it sends ptrace
> events if necessary.
>
> Once this is done, I implemented a similar split for the x86 syscall
> entry work. The C callback is invoked in two phases: the first has
> only a partial frame, and it can request phase 2 processing with a
> full frame.
>
> Finally, I switch the 64-bit system_call code to use the new split
> entry work. This is a net deletion of assembly code: it replaces
> all of the audit entry muck.
>
> In the process, I fixed some bugs.
>
> If this is acceptable, someone can do the same tweak for the
> ia32entry and entry_32 code.
>
> This passes all seccomp tests that I know of. Now that it's properly
> rebased, even the previously expected failures are gone.
>
> Kees, if you like this version, can you create a branch with patches
> 1-4? I think that the rest should go into tip/x86 once everyone's happy
> with it.
>
> Changes from v2:
> - Fixed 32-bit x86 build (and the tests pass).
> - Put the doc patch where it belongs.
Thanks! This looks good to me. I'll add it to my tree.
Peter, how do you feel about this series? Do the x86 changes look good to you?
-Kees
>
> Changes from v1:
> - Rebased on top of Kees' shiny new seccomp tree (no effect on the x86
> part).
> - Improved patch 6 vs patch 7 split (thanks Alexei!)
> - Fixed bogus -ENOSYS in patch 5 (thanks Kees!)
> - Improved changelog message in patch 6.
>
> Changes from RFC version:
> - The first three patches are more or less the same
> - The rest is more or less a rewrite
>
> Andy Lutomirski (8):
> seccomp,x86,arm,mips,s390: Remove nr parameter from secure_computing
> seccomp: Refactor the filter callback and the API
> seccomp: Allow arch code to provide seccomp_data
> seccomp: Document two-phase seccomp and arch-provided seccomp_data
> x86,x32,audit: Fix x32's AUDIT_ARCH wrt audit
> x86: Split syscall_trace_enter into two phases
> x86_64,entry: Treat regs->ax the same in fastpath and slowpath
> syscalls
> x86_64,entry: Use split-phase syscall_trace_enter for 64-bit syscalls
>
> arch/Kconfig | 11 ++
> arch/arm/kernel/ptrace.c | 7 +-
> arch/mips/kernel/ptrace.c | 2 +-
> arch/s390/kernel/ptrace.c | 2 +-
> arch/x86/include/asm/calling.h | 6 +-
> arch/x86/include/asm/ptrace.h | 5 +
> arch/x86/kernel/entry_64.S | 51 ++++-----
> arch/x86/kernel/ptrace.c | 150 +++++++++++++++++++-----
> arch/x86/kernel/vsyscall_64.c | 2 +-
> include/linux/seccomp.h | 25 ++--
> kernel/seccomp.c | 252 ++++++++++++++++++++++++++++-------------
> 11 files changed, 360 insertions(+), 153 deletions(-)
>
> --
> 1.9.3
>
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* [PATCH 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
From: Javier Martinez Canillas @ 2014-07-22 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WhTdyinkmZFVW5VxK1m-1Z=gMmofBU1RC0t82oEDEZzA@mail.gmail.com>
Hello Yuvaraj,
On Sat, Jun 28, 2014 at 12:47 AM, Doug Anderson <dianders@chromium.org> wrote:
> On Fri, Jun 27, 2014 at 3:59 AM, Yuvaraj Kumar <yuvaraj.cd@gmail.com> wrote:
>>>> mmc_regulator_set_ocr() is failing as its a fixed-regulator.
>>>
>>> Can you explain more about what's failing? It sure looks like mmc
>>> core is supposed to handle this given comments below
>>>
>>> /*
>>> * If we're using a fixed/static regulator, don't call
>>> * regulator_set_voltage; it would fail.
>>> */
>> tps65090 driver does not register through fixed regulator framework.It
>> uses normal regulator framework and supports only
>> enable/disable/is_enabled callbacks.Also it lacks certain callbacks
>> for list_voltage, get_voltage ,set_voltage etc.
>> [ 2.306476] dwmmc_exynos 12220000.mmc: Failed getting OCR mask: -22
>> [ 2.393403] dwmmc_exynos 12220000.mmc: could not set regulator OCR (-22)
>> For the above reason,regulator framework treats fet4 as unused
>> regulator and disables the vmmc regulator.
>
> Ah. Perhaps tps65090 needs to be fixed then... I'm not sure any
> other drivers cared before so maybe that's why it was never caught?
>
I've been looking at this and as Doug and you said it seems that
nobody cared and since the tps65090 fets are actually just load
switches the driver only implementes the .enable and .disable
functions handlers. Also since their output voltage is just equal to
their input supply, that information was not present neither in the
driver nor in the Device Tree.
But when fet4 is used as the vmmc-supply phandle,
mmc_regulator_get_supply() calls mmc_regulator_get_ocrmask() [0] which
expects to fetch the regulator voltage count and current voltage as
you had explained so the function was failing.
Now I don't think that the driver needs to implement the
{get,set,list}_voltage callbacks. If a tps65090 regulator has both
regulator-min-microvolt and regulator-max-microvolt properties from
the generic regulator DT binding, and the value is the same, it can be
assumed that the regulator is fixed and the fixed_uV field can be set
to the output voltage and n_voltages to 1. That's everything that the
regulator core needs from a fixed regulator in order to make
regulator_get_voltage() to succeed:
static int _regulator_get_voltage(struct regulator_dev *rdev)
{
...
if (rdev->desc->ops->get_voltage_sel) {
sel = rdev->desc->ops->get_voltage_sel(rdev);
if (sel < 0)
return sel;
ret = rdev->desc->ops->list_voltage(rdev, sel);
} else if (rdev->desc->ops->get_voltage) {
ret = rdev->desc->ops->get_voltage(rdev);
} else if (rdev->desc->ops->list_voltage) {
ret = rdev->desc->ops->list_voltage(rdev, 0);
} else if (rdev->desc->fixed_uV && (rdev->desc->n_voltages == 1)) {
ret = rdev->desc->fixed_uV;
} else {
return -EINVAL;
}
...
}
What do you think about patch [1]?
So, with that patch mmc_regulator_get_supply() does not fail anymore
and also does not break DT backward compatibility since it only has
effect on the regulators that define their min and max voltage and not
in the ones that don't like is the case in old DTB.
Now, it is an RFC since I don't know if this is the correct solution.
Even though I've seen that min == max seems to imply that the
regulator is fixed, I wonder if is better to have an explicit generic
DT property (regulator-fixed-microvolt?) that is used to set fixed_uV
in of_get_regulation_constraints(). Since this seems to be a general
problem and not only related to the tps65090 device or the Peach
Pit/Pi use case. If you agree that it's a good solution then I can
post it as a proper patch.
I've also pushed this patch and the ones adding the needed DTS bits
for Peach Pit and Pi DTS to my personal repository so you can test it.
The branch is:
http://cgit.collabora.com/git/user/javier/linux.git/log/?h=tps65090-fixes
You also need to replace regulator_enable(mmc->supply.vmmc) and
regulator_disable(mmc->supply.vmmc) by mmc_regulator_set_ocr(mmc,
mmc->supply.vmmc, ios->vdd) and mmc_regulator_set_ocr(mmc,
mmc->supply.vmmc, 0) respectively in your original patch.
Best regards,
Javier
[0]: http://lxr.free-electrons.com/source/drivers/mmc/core/core.c#L1215
[1]:
>From 3d2e6079cc8c372da946d430d43d36af99e7a582 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Tue, 22 Jul 2014 19:16:47 +0200
Subject: [RFC] regulator: tps65090: Allow regulators voltage to be
queried
The tps65090 device has some regulators with a fixed output
voltage and others with an adjustable output voltage. But the
regulators with adjustable output just provide the voltage of
their input supply so they really are fixed regulators within
a supported voltage range that depends on their input voltage.
That is why the driver only provides an .enable and .disable
function handlers and not a .{get,set,list}_voltage handlers.
But there is code in the kernel that expects to query the
output voltage for all regulators. For example the function
mmc_regulator_get_ocrmask() is executed if a regulator is
used as a vmmc supply and this functions tries to fetch the
number of voltages supported by the regulator and its current
voltage but fails since the driver does not provide this data.
The .{list,get}_voltage function handler are actually not even
needed for fixed regulators since in this case the regulator
core just need a fixed voltage and a single voltage selector.
So, let's allow output voltage to be defined using the generic
regulator-min-microvolt and regulator-max-microvolt properties
and use the same semantic for fixed regulator as explained in
Documentation/devicetree/bindings/regulator/fixed-regulator.txt.
Where having an equal value for min and max microvolt means that
the regulator is fixed and has a single voltage selector.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
drivers/regulator/tps65090-regulator.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 2064b3f..673948d 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -408,6 +408,7 @@ static int tps65090_regulator_probe(struct
platform_device *pdev)
struct of_regulator_match *tps65090_reg_matches = NULL;
int num;
int ret;
+ int min_uV, max_uV;
dev_dbg(&pdev->dev, "Probing regulator\n");
@@ -435,6 +436,19 @@ static int tps65090_regulator_probe(struct
platform_device *pdev)
ri->overcurrent_wait_valid =
tps_pdata->overcurrent_wait_valid;
ri->overcurrent_wait = tps_pdata->overcurrent_wait;
+
+ min_uV = tps_pdata->reg_init_data->constraints.min_uV;
+ max_uV = tps_pdata->reg_init_data->constraints.max_uV;
+
+ /*
+ * A regulator whose regulator-min-microvolt and
+ * regulator-max-microvolt properties are the same
+ * is a fixed regulator and has a single voltage rail.
+ */
+ if (min_uV && max_uV && min_uV == max_uV) {
+ ri->desc->fixed_uV = min_uV;
+ ri->desc->n_voltages = 1;
+ }
}
/*
--
2.0.0.rc2
^ permalink raw reply related
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