ST's platforms often have multiple co-processors (usually ST40s or ST231s)
on-board. This provides the Linux-side infrastructure to flash and boot
them successfully.
This set has been tested on an STiH410-B2120.
v3 => v4:
Suggested-by: Suman Anna <[email protected]>
- Move to using 'reserved-memory' API
- New 'reserved-memory' nodes
- Remove memory locations from RemoteProc's DT node's reg properties
- Remove C code obtaining/allocating DMA memory
- Re-order .start() and .stop() ops
- Add protection around Reset API in error path
- Explicitly set .has_iommu to false
v2 => v3:
- Generify syscon property (st,syscfg-boot => st,syscfg)
- Rename IP in DT bindings doc (Remote Processor => Co-Processor)
- Remove superfluous 'clock-names' property
- Remove superfluous 'reg-names' property
- Populate MAINTAINERS
- Clean-up DTS formatting
- Use strings in debugfs to control procs ('1|0' => 'start|stop')
- Align copyright statement with MODULE() macros
- Rename driver data structure ('st_rproc' => 'ddata')
- Addition of a full error path in .start()
v1 => v2:
- Remove Linux implementation specific comment from binding document
- Force debugfs '0' to shutdown co-processor - rather than !1
- Supply more detailed commit message
- Propagate errors back from .stop()
- Review GPL wording
- Supply original author's SoBs
Lee Jones (6):
remoteproc: dt: Provide bindings for ST's Remote Processor Controller
driver
remoteproc: debugfs: Add ability to boot remote processor using
debugfs
remoteproc: Supply controller driver for ST's Remote Processors
MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
ARM: STiH407: Add nodes for RemoteProc
ARM: STiH407: Move over to using the 'reserved-memory' API for
obtaining DMA memory
.../devicetree/bindings/remoteproc/st-rproc.txt | 41 +++
MAINTAINERS | 1 +
arch/arm/boot/dts/stih407-family.dtsi | 70 +++++
drivers/remoteproc/Kconfig | 9 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/remoteproc_debugfs.c | 34 +++
drivers/remoteproc/st_remoteproc.c | 297 +++++++++++++++++++++
7 files changed, 453 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
create mode 100644 drivers/remoteproc/st_remoteproc.c
--
1.9.1
Signed-off-by: Ludovic Barre <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
.../devicetree/bindings/remoteproc/st-rproc.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
new file mode 100644
index 0000000..1031bcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
@@ -0,0 +1,41 @@
+STMicroelectronics Co-Processor Bindings
+----------------------------------------
+
+This binding provides support for adjunct processors found on ST SoCs.
+
+Co-processors can be controlled from the bootloader or the primary OS. If
+the bootloader starts a co-processor, the primary OS must detect its state
+and act accordingly.
+
+Required properties:
+- compatible Should be one of:
+ "st,st231-rproc"
+ "st,st40-rproc"
+- memory-region Reserved memory (See: ../reserved-memory/reserved-memory.txt)
+- resets Reset lines (See: ../reset/reset.txt)
+- reset-names Must be "sw_reset" and "pwr_reset"
+- clocks Clock for co-processor (See: ../clock/clock-bindings.txt)
+- clock-frequency Clock frequency to set co-processor at if the bootloader
+ hasn't already done so
+- st,syscfg System configuration register which holds the boot vector
+ for the co-processor
+ 1st cell: Phandle to syscon block
+ 2nd cell: Boot vector register offset
+
+Example:
+
+ audio_reserved: rproc@42000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x42000000 0x01000000>;
+ no-map;
+ };
+
+ st231-audio {
+ compatible = "st,st231-rproc";
+ memory-region = <&audio_reserved>;
+ resets = <&softreset STIH407_ST231_AUD_SOFTRESET>;
+ reset-names = "sw_reset";
+ clocks = <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
+ clock-frequency = <600000000>;
+ st,syscfg = <&syscfg_core 0x228>;
+ };
--
1.9.1
This functionality is especially useful during the testing phase. When
used in conjunction with Mailbox's Test Framework we can trivially conduct
end-to-end testing i.e. boot co-processor, send and receive messages to
the co-processor, then shut it down again (repeat as required).
Signed-off-by: Ludovic Barre <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
drivers/remoteproc/remoteproc_debugfs.c | 34 +++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
index 9d30809..8113c18 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -88,8 +88,42 @@ static ssize_t rproc_state_read(struct file *filp, char __user *userbuf,
return simple_read_from_buffer(userbuf, count, ppos, buf, i);
}
+static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ struct rproc *rproc = filp->private_data;
+ char buf[10];
+ int ret;
+
+ if (count > sizeof(buf))
+ return count;
+
+ ret = copy_from_user(buf, userbuf, count);
+ if (ret)
+ return -EFAULT;
+
+ if (buf[count - 1] == '\n')
+ buf[count - 1] = '\0';
+
+ if (!strncmp(buf, "start", count)) {
+ ret = rproc_boot(rproc);
+ if (ret) {
+ dev_err(&rproc->dev, "Boot failed: %d\n", ret);
+ return ret;
+ }
+ } else if (!strncmp(buf, "stop", count)) {
+ rproc_shutdown(rproc);
+ } else {
+ dev_err(&rproc->dev, "Unrecognised option: %s\n", buf);
+ return -EINVAL;
+ }
+
+ return count;
+}
+
static const struct file_operations rproc_state_ops = {
.read = rproc_state_read,
+ .write = rproc_state_write,
.open = simple_open,
.llseek = generic_file_llseek,
};
--
1.9.1
Signed-off-by: Ludovic Barre <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
drivers/remoteproc/Kconfig | 9 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/st_remoteproc.c | 297 +++++++++++++++++++++++++++++++++++++
3 files changed, 307 insertions(+)
create mode 100644 drivers/remoteproc/st_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 28c711f..72e97d7 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
It's safe to say n here if you're not interested in multimedia
offloading.
+config ST_REMOTEPROC
+ tristate "ST remoteproc support"
+ depends on ARCH_STI
+ select REMOTEPROC
+ help
+ Say y here to support ST's adjunct processors via the remote
+ processor framework.
+ This can be either built-in or a loadable module.
+
endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 81b04d1..279cb2e 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_STE_MODEM_RPROC) += ste_modem_rproc.o
obj-$(CONFIG_WKUP_M3_RPROC) += wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
+obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
new file mode 100644
index 0000000..6bb04d4
--- /dev/null
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -0,0 +1,297 @@
+/*
+ * ST's Remote Processor Control Driver
+ *
+ * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
+ *
+ * Author: Ludovic Barre <[email protected]>
+ *
+ * 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/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/remoteproc.h>
+#include <linux/reset.h>
+
+struct st_rproc_config {
+ bool sw_reset;
+ bool pwr_reset;
+ unsigned long bootaddr_mask;
+};
+
+struct st_rproc {
+ struct st_rproc_config *config;
+ struct reset_control *sw_reset;
+ struct reset_control *pwr_reset;
+ struct clk *clk;
+ u32 clk_rate;
+ struct regmap *boot_base;
+ u32 boot_offset;
+};
+
+static int st_rproc_start(struct rproc *rproc)
+{
+ struct st_rproc *ddata = rproc->priv;
+ int err;
+
+ regmap_update_bits(ddata->boot_base, ddata->boot_offset,
+ ddata->config->bootaddr_mask, rproc->bootaddr);
+
+ err = clk_enable(ddata->clk);
+ if (err) {
+ dev_err(&rproc->dev, "Failed to enable clock\n");
+ return err;
+ }
+
+ if (ddata->config->sw_reset) {
+ err = reset_control_deassert(ddata->sw_reset);
+ if (err) {
+ dev_err(&rproc->dev, "Failed to deassert S/W Reset\n");
+ goto sw_reset_fail;
+ }
+ }
+
+ if (ddata->config->pwr_reset) {
+ err = reset_control_deassert(ddata->pwr_reset);
+ if (err) {
+ dev_err(&rproc->dev, "Failed to deassert Power Reset\n");
+ goto pwr_reset_fail;
+ }
+ }
+
+ dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
+
+ return 0;
+
+
+pwr_reset_fail:
+ if (ddata->config->pwr_reset)
+ reset_control_assert(ddata->sw_reset);
+sw_reset_fail:
+ clk_disable(ddata->clk);
+
+ return err;
+}
+
+static int st_rproc_stop(struct rproc *rproc)
+{
+ struct st_rproc *ddata = rproc->priv;
+ int sw_err = 0, pwr_err = 0;
+
+ if (ddata->config->sw_reset) {
+ sw_err = reset_control_assert(ddata->sw_reset);
+ if (sw_err)
+ dev_err(&rproc->dev, "Failed to assert S/W Reset\n");
+ }
+
+ if (ddata->config->pwr_reset) {
+ pwr_err = reset_control_assert(ddata->pwr_reset);
+ if (pwr_err)
+ dev_err(&rproc->dev, "Failed to assert Power Reset\n");
+ }
+
+ clk_disable(ddata->clk);
+
+ return sw_err ?: pwr_err;
+}
+
+static struct rproc_ops st_rproc_ops = {
+ .start = st_rproc_start,
+ .stop = st_rproc_stop,
+};
+
+/*
+ * Fetch state of the processor: 0 is off, 1 is on.
+ */
+static int st_rproc_state(struct platform_device *pdev)
+{
+ struct rproc *rproc = platform_get_drvdata(pdev);
+ struct st_rproc *ddata = rproc->priv;
+ int reset_sw = 0, reset_pwr = 0;
+
+ if (ddata->config->sw_reset)
+ reset_sw = reset_control_status(ddata->sw_reset);
+
+ if (ddata->config->pwr_reset)
+ reset_pwr = reset_control_status(ddata->pwr_reset);
+
+ if (reset_sw < 0 || reset_pwr < 0)
+ return -EINVAL;
+
+ return !reset_sw && !reset_pwr;
+}
+
+static const struct st_rproc_config st40_rproc_cfg = {
+ .sw_reset = true,
+ .pwr_reset = true,
+ .bootaddr_mask = GENMASK(28, 1),
+};
+
+static const struct st_rproc_config st231_rproc_cfg = {
+ .sw_reset = true,
+ .pwr_reset = false,
+ .bootaddr_mask = GENMASK(31, 6),
+};
+
+static const struct of_device_id st_rproc_match[] = {
+ { .compatible = "st,st40-rproc", .data = &st40_rproc_cfg },
+ { .compatible = "st,st231-rproc", .data = &st231_rproc_cfg },
+ {},
+};
+MODULE_DEVICE_TABLE(of, st_rproc_match);
+
+static int st_rproc_parse_dt(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct rproc *rproc = platform_get_drvdata(pdev);
+ struct st_rproc *ddata = rproc->priv;
+ struct device_node *np = dev->of_node;
+ int err;
+
+ if (ddata->config->sw_reset) {
+ ddata->sw_reset = devm_reset_control_get(dev, "sw_reset");
+ if (IS_ERR(ddata->sw_reset)) {
+ dev_err(dev, "Failed to get S/W Reset\n");
+ return PTR_ERR(ddata->sw_reset);
+ }
+ }
+
+ if (ddata->config->pwr_reset) {
+ ddata->pwr_reset = devm_reset_control_get(dev, "pwr_reset");
+ if (IS_ERR(ddata->pwr_reset)) {
+ dev_err(dev, "Failed to get Power Reset\n");
+ return PTR_ERR(ddata->pwr_reset);
+ }
+ }
+
+ ddata->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(ddata->clk)) {
+ dev_err(dev, "Failed to get clock\n");
+ return PTR_ERR(ddata->clk);
+ }
+
+ err = of_property_read_u32(np, "clock-frequency", &ddata->clk_rate);
+ if (err) {
+ dev_err(dev, "failed to get clock frequency\n");
+ return err;
+ }
+
+ ddata->boot_base = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
+ if (!ddata->boot_base) {
+ dev_err(dev, "Boot base not found\n");
+ return -EINVAL;
+ }
+
+ err = of_property_read_u32_index(np, "st,syscfg", 1,
+ &ddata->boot_offset);
+ if (err) {
+ dev_err(dev, "Boot offset not found\n");
+ return -EINVAL;
+ }
+
+ err = of_reserved_mem_device_init(dev);
+ if (err) {
+ dev_err(dev, "Failed to obtain shared memory\n");
+ return err;
+ }
+
+ err = clk_prepare(ddata->clk);
+ if (err)
+ dev_err(dev, "failed to get clock\n");
+
+ return err;
+}
+
+static int st_rproc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ const struct of_device_id *match;
+ struct st_rproc *ddata;
+ struct device_node *np = dev->of_node;
+ struct rproc *rproc;
+ int enabled;
+ int ret;
+
+ match = of_match_device(st_rproc_match, dev);
+ if (!match || !match->data) {
+ dev_err(dev, "No device match found\n");
+ return -ENODEV;
+ }
+
+ rproc = rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
+ if (!rproc)
+ return -ENOMEM;
+
+ rproc->has_iommu = false;
+ ddata = rproc->priv;
+ ddata->config = (struct st_rproc_config *)match->data;
+
+ platform_set_drvdata(pdev, rproc);
+
+ ret = st_rproc_parse_dt(pdev);
+ if (ret)
+ goto free_rproc;
+
+ enabled = st_rproc_state(pdev);
+ if (enabled < 0)
+ goto free_rproc;
+
+ if (enabled) {
+ atomic_inc(&rproc->power);
+ rproc->state = RPROC_RUNNING;
+ } else {
+ clk_set_rate(ddata->clk, ddata->clk_rate);
+ }
+
+ ret = rproc_add(rproc);
+ if (ret)
+ goto free_rproc;
+
+ return 0;
+
+free_rproc:
+ rproc_put(rproc);
+ return ret;
+}
+
+static int st_rproc_remove(struct platform_device *pdev)
+{
+ struct rproc *rproc = platform_get_drvdata(pdev);
+ struct st_rproc *ddata = rproc->priv;
+
+ rproc_del(rproc);
+
+ clk_disable_unprepare(ddata->clk);
+
+ of_reserved_mem_device_release(&pdev->dev);
+
+ rproc_put(rproc);
+
+ return 0;
+}
+
+static struct platform_driver st_rproc_driver = {
+ .probe = st_rproc_probe,
+ .remove = st_rproc_remove,
+ .driver = {
+ .name = "st-rproc",
+ .of_match_table = of_match_ptr(st_rproc_match),
+ },
+};
+module_platform_driver(st_rproc_driver);
+
+MODULE_DESCRIPTION("ST Remote Processor Control Driver");
+MODULE_AUTHOR("Ludovic Barre <[email protected]>");
+MODULE_LICENSE("GPL v2");
--
1.9.1
Signed-off-by: Lee Jones <[email protected]>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f46784..322f5b4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1538,6 +1538,7 @@ F: drivers/phy/phy-miphy365x.c
F: drivers/phy/phy-stih407-usb.c
F: drivers/phy/phy-stih41x-usb.c
F: drivers/pinctrl/pinctrl-st.c
+F: drivers/remoteproc/st_remoteproc.c
F: drivers/reset/sti/
F: drivers/rtc/rtc-st-lpc.c
F: drivers/tty/serial/st-asc.c
--
1.9.1
Signed-off-by: Ludovic Barre <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
arch/arm/boot/dts/stih407-family.dtsi | 40 +++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 1e4e01925..15c20b6 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -650,5 +650,45 @@
mbox-name = "st231_audio_video";
status = "okay";
};
+
+ st231_gp0: st231-gp0@40000000 {
+ compatible = "st,st231-rproc";
+ reg = <0x40000000 0x01000000>;
+ resets = <&softreset STIH407_ST231_GP0_SOFTRESET>;
+ reset-names = "sw_reset";
+ clocks = <&clk_s_c0_flexgen CLK_ST231_GP_0>;
+ clock-frequency = <600000000>;
+ st,syscfg = <&syscfg_core 0x22c>;
+ };
+
+ st231_gp1: st231-gp1@41000000 {
+ compatible = "st,st231-rproc";
+ reg = <0x41000000 0x01000000>;
+ resets = <&softreset STIH407_ST231_GP1_SOFTRESET>;
+ reset-names = "sw_reset";
+ clocks = <&clk_s_c0_flexgen CLK_ST231_GP_1>;
+ clock-frequency = <600000000>;
+ st,syscfg = <&syscfg_core 0x220>;
+ };
+
+ st231_audio: st231-audio@42000000 {
+ compatible = "st,st231-rproc";
+ reg = <0x42000000 0x01000000>;
+ resets = <&softreset STIH407_ST231_AUD_SOFTRESET>;
+ reset-names = "sw_reset";
+ clocks = <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
+ clock-frequency = <600000000>;
+ st,syscfg = <&syscfg_core 0x228>;
+ };
+
+ st231_dmu: st231-dmu@43000000 {
+ compatible = "st,st231-rproc";
+ reg = <0x43000000 0x01000000>;
+ resets = <&softreset STIH407_ST231_DMU_SOFTRESET>;
+ reset-names = "sw_reset";
+ clocks = <&clk_s_c0_flexgen CLK_ST231_DMU>;
+ clock-frequency = <600000000>;
+ st,syscfg = <&syscfg_core 0x224>;
+ };
};
};
--
1.9.1
Doing so saves quite a bit of code in the driver.
For more information on the 'reserved-memory' bindings see:
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Suggested-by: Suman Anna <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
arch/arm/boot/dts/stih407-family.dtsi | 46 +++++++++++++++++++++++++++++------
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 15c20b6..27b8efc 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -15,6 +15,36 @@
#address-cells = <1>;
#size-cells = <1>;
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ gp0_reserved: rproc@40000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x40000000 0x01000000>;
+ no-map;
+ };
+
+ gp1_reserved: rproc@41000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x41000000 0x01000000>;
+ no-map;
+ };
+
+ audio_reserved: rproc@42000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x42000000 0x01000000>;
+ no-map;
+ };
+
+ dmu_reserved: rproc@43000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x43000000 0x01000000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -651,9 +681,9 @@
status = "okay";
};
- st231_gp0: st231-gp0@40000000 {
+ st231_gp0: st231-gp0 {
compatible = "st,st231-rproc";
- reg = <0x40000000 0x01000000>;
+ memory-region = <&gp0_reserved>;
resets = <&softreset STIH407_ST231_GP0_SOFTRESET>;
reset-names = "sw_reset";
clocks = <&clk_s_c0_flexgen CLK_ST231_GP_0>;
@@ -661,9 +691,9 @@
st,syscfg = <&syscfg_core 0x22c>;
};
- st231_gp1: st231-gp1@41000000 {
+ st231_gp1: st231-gp1 {
compatible = "st,st231-rproc";
- reg = <0x41000000 0x01000000>;
+ memory-region = <&gp1_reserved>;
resets = <&softreset STIH407_ST231_GP1_SOFTRESET>;
reset-names = "sw_reset";
clocks = <&clk_s_c0_flexgen CLK_ST231_GP_1>;
@@ -671,9 +701,9 @@
st,syscfg = <&syscfg_core 0x220>;
};
- st231_audio: st231-audio@42000000 {
+ st231_audio: st231-audio {
compatible = "st,st231-rproc";
- reg = <0x42000000 0x01000000>;
+ memory-region = <&audio_reserved>;
resets = <&softreset STIH407_ST231_AUD_SOFTRESET>;
reset-names = "sw_reset";
clocks = <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
@@ -681,9 +711,9 @@
st,syscfg = <&syscfg_core 0x228>;
};
- st231_dmu: st231-dmu@43000000 {
+ st231_dmu: st231-dmu {
compatible = "st,st231-rproc";
- reg = <0x43000000 0x01000000>;
+ memory-region = <&dmu_reserved>;
resets = <&softreset STIH407_ST231_DMU_SOFTRESET>;
reset-names = "sw_reset";
clocks = <&clk_s_c0_flexgen CLK_ST231_DMU>;
--
1.9.1
On Tue, Nov 24, 2015 at 01:14:17PM +0000, Lee Jones wrote:
> Signed-off-by: Ludovic Barre <[email protected]>
> Signed-off-by: Lee Jones <[email protected]>
> ---
> .../devicetree/bindings/remoteproc/st-rproc.txt | 41 ++++++++++++++++++++++
Acked-by: Rob Herring <[email protected]>
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> new file mode 100644
> index 0000000..1031bcd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> @@ -0,0 +1,41 @@
> +STMicroelectronics Co-Processor Bindings
> +----------------------------------------
> +
> +This binding provides support for adjunct processors found on ST SoCs.
> +
> +Co-processors can be controlled from the bootloader or the primary OS. If
> +the bootloader starts a co-processor, the primary OS must detect its state
> +and act accordingly.
> +
> +Required properties:
> +- compatible Should be one of:
> + "st,st231-rproc"
> + "st,st40-rproc"
> +- memory-region Reserved memory (See: ../reserved-memory/reserved-memory.txt)
> +- resets Reset lines (See: ../reset/reset.txt)
> +- reset-names Must be "sw_reset" and "pwr_reset"
> +- clocks Clock for co-processor (See: ../clock/clock-bindings.txt)
> +- clock-frequency Clock frequency to set co-processor at if the bootloader
> + hasn't already done so
> +- st,syscfg System configuration register which holds the boot vector
> + for the co-processor
> + 1st cell: Phandle to syscon block
> + 2nd cell: Boot vector register offset
> +
> +Example:
> +
> + audio_reserved: rproc@42000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x42000000 0x01000000>;
> + no-map;
> + };
> +
> + st231-audio {
> + compatible = "st,st231-rproc";
> + memory-region = <&audio_reserved>;
> + resets = <&softreset STIH407_ST231_AUD_SOFTRESET>;
> + reset-names = "sw_reset";
> + clocks = <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
> + clock-frequency = <600000000>;
> + st,syscfg = <&syscfg_core 0x228>;
> + };
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Lee,
On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones <[email protected]> wrote:
> ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> on-board. This provides the Linux-side infrastructure to flash and boot
> them successfully.
>
> This set has been tested on an STiH410-B2120.
It would be nice if you could get at least one Reviewed-by tag coming
outside of ST (e.g., Suman or Bjorn who are actively using and
improving remoteproc).
> arch/arm/boot/dts/stih407-family.dtsi | 70 +++++
Since this is outside of remoteproc, please have it Acked, preferably
by ARM DT maintainer (Olof?).
Thanks,
Ohad.
On Thu, 26 Nov 2015, Ohad Ben-Cohen wrote:
> On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones <[email protected]> wrote:
> > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> > on-board. This provides the Linux-side infrastructure to flash and boot
> > them successfully.
> >
> > This set has been tested on an STiH410-B2120.
>
> It would be nice if you could get at least one Reviewed-by tag coming
> outside of ST (e.g., Suman or Bjorn who are actively using and
> improving remoteproc).
If you require reviews by these guys, shouldn't they be Maintainers?
> > arch/arm/boot/dts/stih407-family.dtsi | 70 +++++
>
> Since this is outside of remoteproc, please have it Acked, preferably
> by ARM DT maintainer (Olof?).
The bindings have already been Acked by Rob. So long as the DTS(I)
files conform to them, there should be no issue. Please be aware that
the DTS(I) changes are applied to this set for your information only
and are not to be applied through the RemoteProc tree. The usual
process to which we conform is that Maxime (the STi Maintainer) will
apply the DT changes *after* the main driver has been applied, in this
case by you.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Thu, Nov 26, 2015 at 11:10 AM, Lee Jones <[email protected]> wrote:
> On Thu, 26 Nov 2015, Ohad Ben-Cohen wrote:
>> On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones <[email protected]> wrote:
>> > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
>> > on-board. This provides the Linux-side infrastructure to flash and boot
>> > them successfully.
>> >
>> > This set has been tested on an STiH410-B2120.
>>
>> It would be nice if you could get at least one Reviewed-by tag coming
>> outside of ST (e.g., Suman or Bjorn who are actively using and
>> improving remoteproc).
>
> If you require reviews by these guys, shouldn't they be Maintainers?
Additional review isn't a requirement, but it's a plus.
> Please be aware that
> the DTS(I) changes are applied to this set for your information only
> and are not to be applied through the RemoteProc tree. The usual
> process to which we conform is that Maxime (the STi Maintainer) will
> apply the DT changes *after* the main driver has been applied, in this
> case by you.
Ok, great, so I will not take patches 5 and 6.
Thanks,
Ohad.
On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones <[email protected]> wrote:
> This functionality is especially useful during the testing phase. When
> used in conjunction with Mailbox's Test Framework we can trivially conduct
> end-to-end testing i.e. boot co-processor, send and receive messages to
> the co-processor, then shut it down again (repeat as required).
>
I want this too!
> Signed-off-by: Ludovic Barre <[email protected]>
> Signed-off-by: Lee Jones <[email protected]>
> ---
> drivers/remoteproc/remoteproc_debugfs.c | 34 +++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
> index 9d30809..8113c18 100644
> --- a/drivers/remoteproc/remoteproc_debugfs.c
> +++ b/drivers/remoteproc/remoteproc_debugfs.c
> @@ -88,8 +88,42 @@ static ssize_t rproc_state_read(struct file *filp, char __user *userbuf,
> return simple_read_from_buffer(userbuf, count, ppos, buf, i);
> }
>
> +static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
> + size_t count, loff_t *ppos)
> +{
> + struct rproc *rproc = filp->private_data;
> + char buf[10];
> + int ret;
> +
> + if (count > sizeof(buf))
> + return count;
> +
> + ret = copy_from_user(buf, userbuf, count);
> + if (ret)
> + return -EFAULT;
> +
> + if (buf[count - 1] == '\n')
> + buf[count - 1] = '\0';
I believe you can get here with count = 0.
> +
> + if (!strncmp(buf, "start", count)) {
> + ret = rproc_boot(rproc);
> + if (ret) {
> + dev_err(&rproc->dev, "Boot failed: %d\n", ret);
> + return ret;
> + }
> + } else if (!strncmp(buf, "stop", count)) {
> + rproc_shutdown(rproc);
> + } else {
> + dev_err(&rproc->dev, "Unrecognised option: %s\n", buf);
Unrecognized
> + return -EINVAL;
> + }
> +
> + return count;
> +}
> +
> static const struct file_operations rproc_state_ops = {
> .read = rproc_state_read,
> + .write = rproc_state_write,
> .open = simple_open,
> .llseek = generic_file_llseek,
> };
Part of these nits
Acked-by: Bjorn Andersson <[email protected]>
Regards,
Bjorn
On Fri, 27 Nov 2015, Bjorn Andersson wrote:
> On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones <[email protected]> wrote:
> > This functionality is especially useful during the testing phase. When
> > used in conjunction with Mailbox's Test Framework we can trivially conduct
> > end-to-end testing i.e. boot co-processor, send and receive messages to
> > the co-processor, then shut it down again (repeat as required).
> >
>
> I want this too!
>
> > Signed-off-by: Ludovic Barre <[email protected]>
> > Signed-off-by: Lee Jones <[email protected]>
> > ---
> > drivers/remoteproc/remoteproc_debugfs.c | 34 +++++++++++++++++++++++++++++++++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
> > index 9d30809..8113c18 100644
> > --- a/drivers/remoteproc/remoteproc_debugfs.c
> > +++ b/drivers/remoteproc/remoteproc_debugfs.c
> > @@ -88,8 +88,42 @@ static ssize_t rproc_state_read(struct file *filp, char __user *userbuf,
> > return simple_read_from_buffer(userbuf, count, ppos, buf, i);
> > }
> >
> > +static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
> > + size_t count, loff_t *ppos)
> > +{
> > + struct rproc *rproc = filp->private_data;
> > + char buf[10];
> > + int ret;
> > +
> > + if (count > sizeof(buf))
> > + return count;
> > +
> > + ret = copy_from_user(buf, userbuf, count);
> > + if (ret)
> > + return -EFAULT;
> > +
> > + if (buf[count - 1] == '\n')
> > + buf[count - 1] = '\0';
>
> I believe you can get here with count = 0.
I'm pretty sure you can't.
If you are sure that you can, if you can provide me with a way of
testing, I'd be happy to put in provisions.
> > +
> > + if (!strncmp(buf, "start", count)) {
> > + ret = rproc_boot(rproc);
> > + if (ret) {
> > + dev_err(&rproc->dev, "Boot failed: %d\n", ret);
> > + return ret;
> > + }
> > + } else if (!strncmp(buf, "stop", count)) {
> > + rproc_shutdown(rproc);
> > + } else {
> > + dev_err(&rproc->dev, "Unrecognised option: %s\n", buf);
>
> Unrecognized
What I have is correct.
> > + return -EINVAL;
> > + }
> > +
> > + return count;
> > +}
> > +
> > static const struct file_operations rproc_state_ops = {
> > .read = rproc_state_read,
> > + .write = rproc_state_write,
> > .open = simple_open,
> > .llseek = generic_file_llseek,
> > };
>
> Part of these nits
>
> Acked-by: Bjorn Andersson <[email protected]>
Thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Thursday 03 December 2015 12:26:34 Lee Jones wrote:
> > >
> > > +static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
> > > + size_t count, loff_t *ppos)
> > > +{
> > > + struct rproc *rproc = filp->private_data;
> > > + char buf[10];
> > > + int ret;
> > > +
> > > + if (count > sizeof(buf))
> > > + return count;
> > > + ret = copy_from_user(buf, userbuf, count);
> > > + if (ret)
> > > + return -EFAULT;
> > > +
> > > + if (buf[count - 1] == '\n')
> > > + buf[count - 1] = '\0';
> >
> > I believe you can get here with count = 0.
>
> I'm pretty sure you can't.
>
> If you are sure that you can, if you can provide me with a way of
> testing, I'd be happy to put in provisions.
>
I think that a zero-length write() from user space ends up in the write
file operation.
Also, we get a gcc warning about the out-of-bounds access for code like
this, and checking that count is larger than zero avoids the warning.
Arnd
On Thu, 03 Dec 2015, Arnd Bergmann wrote:
> On Thursday 03 December 2015 12:26:34 Lee Jones wrote:
> > > >
> > > > +static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
> > > > + size_t count, loff_t *ppos)
> > > > +{
> > > > + struct rproc *rproc = filp->private_data;
> > > > + char buf[10];
> > > > + int ret;
> > > > +
> > > > + if (count > sizeof(buf))
> > > > + return count;
> > > > + ret = copy_from_user(buf, userbuf, count);
> > > > + if (ret)
> > > > + return -EFAULT;
> > > > +
> > > > + if (buf[count - 1] == '\n')
> > > > + buf[count - 1] = '\0';
> > >
> > > I believe you can get here with count = 0.
> >
> > I'm pretty sure you can't.
> >
> > If you are sure that you can, if you can provide me with a way of
> > testing, I'd be happy to put in provisions.
> >
>
> I think that a zero-length write() from user space ends up in the write
> file operation.
I tested this and didn't see it enter write(). My conclusion was that
if the file doesn't change, then nothing is triggered.
> Also, we get a gcc warning about the out-of-bounds access for code like
> this, and checking that count is larger than zero avoids the warning.
I did however see this warning and wondered what it was talking
about. Thanks for clarifying. Will fix.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Thursday 03 December 2015 13:03:41 Lee Jones wrote:
> On Thu, 03 Dec 2015, Arnd Bergmann wrote:
>
> > On Thursday 03 December 2015 12:26:34 Lee Jones wrote:
> > > > >
> > > > > +static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
> > > > > + size_t count, loff_t *ppos)
> > > > > +{
> > > > > + struct rproc *rproc = filp->private_data;
> > > > > + char buf[10];
> > > > > + int ret;
> > > > > +
> > > > > + if (count > sizeof(buf))
> > > > > + return count;
> > > > > + ret = copy_from_user(buf, userbuf, count);
> > > > > + if (ret)
> > > > > + return -EFAULT;
> > > > > +
> > > > > + if (buf[count - 1] == '\n')
> > > > > + buf[count - 1] = '\0';
> > > >
> > > > I believe you can get here with count = 0.
> > >
> > > I'm pretty sure you can't.
> > >
> > > If you are sure that you can, if you can provide me with a way of
> > > testing, I'd be happy to put in provisions.
> > >
> >
> > I think that a zero-length write() from user space ends up in the write
> > file operation.
>
> I tested this and didn't see it enter write(). My conclusion was that
> if the file doesn't change, then nothing is triggered.
>
Ah, interesting. I haven't tried myself, and just tried to read the
code. Maybe glibc already catches zero-length writes before it gets
into the kernel, or I just missed the part of the syscall that checks
for this.
arnd
On Thu, 03 Dec 2015, Arnd Bergmann wrote:
> On Thursday 03 December 2015 13:03:41 Lee Jones wrote:
> > On Thu, 03 Dec 2015, Arnd Bergmann wrote:
> >
> > > On Thursday 03 December 2015 12:26:34 Lee Jones wrote:
> > > > > >
> > > > > > +static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
> > > > > > + size_t count, loff_t *ppos)
> > > > > > +{
> > > > > > + struct rproc *rproc = filp->private_data;
> > > > > > + char buf[10];
> > > > > > + int ret;
> > > > > > +
> > > > > > + if (count > sizeof(buf))
> > > > > > + return count;
> > > > > > + ret = copy_from_user(buf, userbuf, count);
> > > > > > + if (ret)
> > > > > > + return -EFAULT;
> > > > > > +
> > > > > > + if (buf[count - 1] == '\n')
> > > > > > + buf[count - 1] = '\0';
> > > > >
> > > > > I believe you can get here with count = 0.
> > > >
> > > > I'm pretty sure you can't.
> > > >
> > > > If you are sure that you can, if you can provide me with a way of
> > > > testing, I'd be happy to put in provisions.
> > > >
> > >
> > > I think that a zero-length write() from user space ends up in the write
> > > file operation.
> >
> > I tested this and didn't see it enter write(). My conclusion was that
> > if the file doesn't change, then nothing is triggered.
> >
>
> Ah, interesting. I haven't tried myself, and just tried to read the
> code. Maybe glibc already catches zero-length writes before it gets
> into the kernel, or I just missed the part of the syscall that checks
> for this.
Glibc is responsible indeed:
http://osxr.org/glibc/source/io/write.c
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Thursday 03 December 2015 17:28:30 Lee Jones wrote:
> >
> > Ah, interesting. I haven't tried myself, and just tried to read the
> > code. Maybe glibc already catches zero-length writes before it gets
> > into the kernel, or I just missed the part of the syscall that checks
> > for this.
>
> Glibc is responsible indeed:
>
> http://osxr.org/glibc/source/io/write.c
Ok, so an attacker can force the stack overflow by calling
syscall(__NR_write, fd, p, 0) if that has any potential value,
but normal users won't hit this case.
Arnd
On Thu, Dec 3, 2015 at 1:12 PM, Arnd Bergmann <[email protected]> wrote:
> On Thursday 03 December 2015 17:28:30 Lee Jones wrote:
>> >
>> > Ah, interesting. I haven't tried myself, and just tried to read the
>> > code. Maybe glibc already catches zero-length writes before it gets
>> > into the kernel, or I just missed the part of the syscall that checks
>> > for this.
>>
>> Glibc is responsible indeed:
>>
>> http://osxr.org/glibc/source/io/write.c
>
> Ok, so an attacker can force the stack overflow by calling
> syscall(__NR_write, fd, p, 0) if that has any potential value,
> but normal users won't hit this case.
>
It seems glibc might be the only libc implementation with this protection.
Regards,
Bjorn
On Thu, 03 Dec 2015, Arnd Bergmann wrote:
> On Thursday 03 December 2015 17:28:30 Lee Jones wrote:
> > >
> > > Ah, interesting. I haven't tried myself, and just tried to read the
> > > code. Maybe glibc already catches zero-length writes before it gets
> > > into the kernel, or I just missed the part of the syscall that checks
> > > for this.
> >
> > Glibc is responsible indeed:
> >
> > http://osxr.org/glibc/source/io/write.c
>
> Ok, so an attacker can force the stack overflow by calling
> syscall(__NR_write, fd, p, 0) if that has any potential value,
> but normal users won't hit this case.
Right. I have fixed the issue (and another one I found) anyway, if
only to rid the GCC warning.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones <[email protected]> wrote:
> Signed-off-by: Ludovic Barre <[email protected]>
> Signed-off-by: Lee Jones <[email protected]>
> ---
Acked-by: Bjorn Andersson <[email protected]>
Regards,
Bjorn
> .../devicetree/bindings/remoteproc/st-rproc.txt | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> new file mode 100644
> index 0000000..1031bcd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> @@ -0,0 +1,41 @@
> +STMicroelectronics Co-Processor Bindings
> +----------------------------------------
> +
> +This binding provides support for adjunct processors found on ST SoCs.
> +
> +Co-processors can be controlled from the bootloader or the primary OS. If
> +the bootloader starts a co-processor, the primary OS must detect its state
> +and act accordingly.
> +
> +Required properties:
> +- compatible Should be one of:
> + "st,st231-rproc"
> + "st,st40-rproc"
> +- memory-region Reserved memory (See: ../reserved-memory/reserved-memory.txt)
> +- resets Reset lines (See: ../reset/reset.txt)
> +- reset-names Must be "sw_reset" and "pwr_reset"
> +- clocks Clock for co-processor (See: ../clock/clock-bindings.txt)
> +- clock-frequency Clock frequency to set co-processor at if the bootloader
> + hasn't already done so
> +- st,syscfg System configuration register which holds the boot vector
> + for the co-processor
> + 1st cell: Phandle to syscon block
> + 2nd cell: Boot vector register offset
> +
> +Example:
> +
> + audio_reserved: rproc@42000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x42000000 0x01000000>;
> + no-map;
> + };
> +
> + st231-audio {
> + compatible = "st,st231-rproc";
> + memory-region = <&audio_reserved>;
> + resets = <&softreset STIH407_ST231_AUD_SOFTRESET>;
> + reset-names = "sw_reset";
> + clocks = <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
> + clock-frequency = <600000000>;
> + st,syscfg = <&syscfg_core 0x228>;
> + };
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones <[email protected]> wrote:
> Signed-off-by: Ludovic Barre <[email protected]>
> Signed-off-by: Lee Jones <[email protected]>
> ---
Acked-by: Bjorn Andersson <[email protected]>
Regards,
Bjorn
> drivers/remoteproc/Kconfig | 9 ++
> drivers/remoteproc/Makefile | 1 +
> drivers/remoteproc/st_remoteproc.c | 297 +++++++++++++++++++++++++++++++++++++
> 3 files changed, 307 insertions(+)
> create mode 100644 drivers/remoteproc/st_remoteproc.c
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 28c711f..72e97d7 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
> It's safe to say n here if you're not interested in multimedia
> offloading.
>
> +config ST_REMOTEPROC
> + tristate "ST remoteproc support"
> + depends on ARCH_STI
> + select REMOTEPROC
> + help
> + Say y here to support ST's adjunct processors via the remote
> + processor framework.
> + This can be either built-in or a loadable module.
> +
> endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 81b04d1..279cb2e 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
> obj-$(CONFIG_STE_MODEM_RPROC) += ste_modem_rproc.o
> obj-$(CONFIG_WKUP_M3_RPROC) += wkup_m3_rproc.o
> obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
> +obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
> diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
> new file mode 100644
> index 0000000..6bb04d4
> --- /dev/null
> +++ b/drivers/remoteproc/st_remoteproc.c
> @@ -0,0 +1,297 @@
> +/*
> + * ST's Remote Processor Control Driver
> + *
> + * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
> + *
> + * Author: Ludovic Barre <[email protected]>
> + *
> + * 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/clk.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/remoteproc.h>
> +#include <linux/reset.h>
> +
> +struct st_rproc_config {
> + bool sw_reset;
> + bool pwr_reset;
> + unsigned long bootaddr_mask;
> +};
> +
> +struct st_rproc {
> + struct st_rproc_config *config;
> + struct reset_control *sw_reset;
> + struct reset_control *pwr_reset;
> + struct clk *clk;
> + u32 clk_rate;
> + struct regmap *boot_base;
> + u32 boot_offset;
> +};
> +
> +static int st_rproc_start(struct rproc *rproc)
> +{
> + struct st_rproc *ddata = rproc->priv;
> + int err;
> +
> + regmap_update_bits(ddata->boot_base, ddata->boot_offset,
> + ddata->config->bootaddr_mask, rproc->bootaddr);
> +
> + err = clk_enable(ddata->clk);
> + if (err) {
> + dev_err(&rproc->dev, "Failed to enable clock\n");
> + return err;
> + }
> +
> + if (ddata->config->sw_reset) {
> + err = reset_control_deassert(ddata->sw_reset);
> + if (err) {
> + dev_err(&rproc->dev, "Failed to deassert S/W Reset\n");
> + goto sw_reset_fail;
> + }
> + }
> +
> + if (ddata->config->pwr_reset) {
> + err = reset_control_deassert(ddata->pwr_reset);
> + if (err) {
> + dev_err(&rproc->dev, "Failed to deassert Power Reset\n");
> + goto pwr_reset_fail;
> + }
> + }
> +
> + dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
> +
> + return 0;
> +
> +
> +pwr_reset_fail:
> + if (ddata->config->pwr_reset)
> + reset_control_assert(ddata->sw_reset);
> +sw_reset_fail:
> + clk_disable(ddata->clk);
> +
> + return err;
> +}
> +
> +static int st_rproc_stop(struct rproc *rproc)
> +{
> + struct st_rproc *ddata = rproc->priv;
> + int sw_err = 0, pwr_err = 0;
> +
> + if (ddata->config->sw_reset) {
> + sw_err = reset_control_assert(ddata->sw_reset);
> + if (sw_err)
> + dev_err(&rproc->dev, "Failed to assert S/W Reset\n");
> + }
> +
> + if (ddata->config->pwr_reset) {
> + pwr_err = reset_control_assert(ddata->pwr_reset);
> + if (pwr_err)
> + dev_err(&rproc->dev, "Failed to assert Power Reset\n");
> + }
> +
> + clk_disable(ddata->clk);
> +
> + return sw_err ?: pwr_err;
> +}
> +
> +static struct rproc_ops st_rproc_ops = {
> + .start = st_rproc_start,
> + .stop = st_rproc_stop,
> +};
> +
> +/*
> + * Fetch state of the processor: 0 is off, 1 is on.
> + */
> +static int st_rproc_state(struct platform_device *pdev)
> +{
> + struct rproc *rproc = platform_get_drvdata(pdev);
> + struct st_rproc *ddata = rproc->priv;
> + int reset_sw = 0, reset_pwr = 0;
> +
> + if (ddata->config->sw_reset)
> + reset_sw = reset_control_status(ddata->sw_reset);
> +
> + if (ddata->config->pwr_reset)
> + reset_pwr = reset_control_status(ddata->pwr_reset);
> +
> + if (reset_sw < 0 || reset_pwr < 0)
> + return -EINVAL;
> +
> + return !reset_sw && !reset_pwr;
> +}
> +
> +static const struct st_rproc_config st40_rproc_cfg = {
> + .sw_reset = true,
> + .pwr_reset = true,
> + .bootaddr_mask = GENMASK(28, 1),
> +};
> +
> +static const struct st_rproc_config st231_rproc_cfg = {
> + .sw_reset = true,
> + .pwr_reset = false,
> + .bootaddr_mask = GENMASK(31, 6),
> +};
> +
> +static const struct of_device_id st_rproc_match[] = {
> + { .compatible = "st,st40-rproc", .data = &st40_rproc_cfg },
> + { .compatible = "st,st231-rproc", .data = &st231_rproc_cfg },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, st_rproc_match);
> +
> +static int st_rproc_parse_dt(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct rproc *rproc = platform_get_drvdata(pdev);
> + struct st_rproc *ddata = rproc->priv;
> + struct device_node *np = dev->of_node;
> + int err;
> +
> + if (ddata->config->sw_reset) {
> + ddata->sw_reset = devm_reset_control_get(dev, "sw_reset");
> + if (IS_ERR(ddata->sw_reset)) {
> + dev_err(dev, "Failed to get S/W Reset\n");
> + return PTR_ERR(ddata->sw_reset);
> + }
> + }
> +
> + if (ddata->config->pwr_reset) {
> + ddata->pwr_reset = devm_reset_control_get(dev, "pwr_reset");
> + if (IS_ERR(ddata->pwr_reset)) {
> + dev_err(dev, "Failed to get Power Reset\n");
> + return PTR_ERR(ddata->pwr_reset);
> + }
> + }
> +
> + ddata->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(ddata->clk)) {
> + dev_err(dev, "Failed to get clock\n");
> + return PTR_ERR(ddata->clk);
> + }
> +
> + err = of_property_read_u32(np, "clock-frequency", &ddata->clk_rate);
> + if (err) {
> + dev_err(dev, "failed to get clock frequency\n");
> + return err;
> + }
> +
> + ddata->boot_base = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
> + if (!ddata->boot_base) {
> + dev_err(dev, "Boot base not found\n");
> + return -EINVAL;
> + }
> +
> + err = of_property_read_u32_index(np, "st,syscfg", 1,
> + &ddata->boot_offset);
> + if (err) {
> + dev_err(dev, "Boot offset not found\n");
> + return -EINVAL;
> + }
> +
> + err = of_reserved_mem_device_init(dev);
> + if (err) {
> + dev_err(dev, "Failed to obtain shared memory\n");
> + return err;
> + }
> +
> + err = clk_prepare(ddata->clk);
> + if (err)
> + dev_err(dev, "failed to get clock\n");
> +
> + return err;
> +}
> +
> +static int st_rproc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + const struct of_device_id *match;
> + struct st_rproc *ddata;
> + struct device_node *np = dev->of_node;
> + struct rproc *rproc;
> + int enabled;
> + int ret;
> +
> + match = of_match_device(st_rproc_match, dev);
> + if (!match || !match->data) {
> + dev_err(dev, "No device match found\n");
> + return -ENODEV;
> + }
> +
> + rproc = rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
> + if (!rproc)
> + return -ENOMEM;
> +
> + rproc->has_iommu = false;
> + ddata = rproc->priv;
> + ddata->config = (struct st_rproc_config *)match->data;
> +
> + platform_set_drvdata(pdev, rproc);
> +
> + ret = st_rproc_parse_dt(pdev);
> + if (ret)
> + goto free_rproc;
> +
> + enabled = st_rproc_state(pdev);
> + if (enabled < 0)
> + goto free_rproc;
> +
> + if (enabled) {
> + atomic_inc(&rproc->power);
> + rproc->state = RPROC_RUNNING;
> + } else {
> + clk_set_rate(ddata->clk, ddata->clk_rate);
> + }
> +
> + ret = rproc_add(rproc);
> + if (ret)
> + goto free_rproc;
> +
> + return 0;
> +
> +free_rproc:
> + rproc_put(rproc);
> + return ret;
> +}
> +
> +static int st_rproc_remove(struct platform_device *pdev)
> +{
> + struct rproc *rproc = platform_get_drvdata(pdev);
> + struct st_rproc *ddata = rproc->priv;
> +
> + rproc_del(rproc);
> +
> + clk_disable_unprepare(ddata->clk);
> +
> + of_reserved_mem_device_release(&pdev->dev);
> +
> + rproc_put(rproc);
> +
> + return 0;
> +}
> +
> +static struct platform_driver st_rproc_driver = {
> + .probe = st_rproc_probe,
> + .remove = st_rproc_remove,
> + .driver = {
> + .name = "st-rproc",
> + .of_match_table = of_match_ptr(st_rproc_match),
> + },
> +};
> +module_platform_driver(st_rproc_driver);
> +
> +MODULE_DESCRIPTION("ST Remote Processor Control Driver");
> +MODULE_AUTHOR("Ludovic Barre <[email protected]>");
> +MODULE_LICENSE("GPL v2");
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Dec 4, 2015 at 12:24 AM, Lee Jones <[email protected]> wrote:
> On Thu, 03 Dec 2015, Arnd Bergmann wrote:
>
>> On Thursday 03 December 2015 17:28:30 Lee Jones wrote:
>> > >
>> > > Ah, interesting. I haven't tried myself, and just tried to read the
>> > > code. Maybe glibc already catches zero-length writes before it gets
>> > > into the kernel, or I just missed the part of the syscall that checks
>> > > for this.
>> >
>> > Glibc is responsible indeed:
>> >
>> > http://osxr.org/glibc/source/io/write.c
>>
>> Ok, so an attacker can force the stack overflow by calling
>> syscall(__NR_write, fd, p, 0) if that has any potential value,
>> but normal users won't hit this case.
>
> Right. I have fixed the issue (and another one I found) anyway, if
> only to rid the GCC warning.
>
Sorry, but I'm unable to find a new version of this patch, did I miss
it or could you resend it?
Also, as I looked at this again, we should probably return an error if
count >= sizeof(buf) rather than just acknowledging the input (same in
the other debugfs write function in this file).
Regards,
Bjorn
On Thu, Nov 26, 2015 at 1:32 AM, Ohad Ben-Cohen <[email protected]> wrote:
> On Thu, Nov 26, 2015 at 11:10 AM, Lee Jones <[email protected]> wrote:
>> On Thu, 26 Nov 2015, Ohad Ben-Cohen wrote:
>>> On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones <[email protected]> wrote:
>>> > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
>>> > on-board. This provides the Linux-side infrastructure to flash and boot
>>> > them successfully.
>>> >
>>> > This set has been tested on an STiH410-B2120.
>>>
>>> It would be nice if you could get at least one Reviewed-by tag coming
>>> outside of ST (e.g., Suman or Bjorn who are actively using and
>>> improving remoteproc).
>>
>> If you require reviews by these guys, shouldn't they be Maintainers?
>
> Additional review isn't a requirement, but it's a plus.
>
>> Please be aware that
>> the DTS(I) changes are applied to this set for your information only
>> and are not to be applied through the RemoteProc tree. The usual
>> process to which we conform is that Maxime (the STi Maintainer) will
>> apply the DT changes *after* the main driver has been applied, in this
>> case by you.
>
> Ok, great, so I will not take patches 5 and 6.
>
I interpreted this as you picked patch 1-4 and didn't pay more
attention to them, but I can't find them in your kernel.org trees. So
I've looked through them again.
Please apply patch 1, 3 and 4 to your tree Ohad. I was unable to find
a v5 of patch 2, but it's unrelated so no need to wait for a new
version of that.
Regards,
Bjorn
On Mon, Dec 28, 2015 at 8:41 PM, Bjorn Andersson <[email protected]> wrote:
> I interpreted this as you picked patch 1-4 and didn't pay more
> attention to them, but I can't find them in your kernel.org trees. So
> I've looked through them again.
>
> Please apply patch 1, 3 and 4 to your tree Ohad. I was unable to find
> a v5 of patch 2, but it's unrelated so no need to wait for a new
> version of that.
I was under the impression that Lee plans to resubmit once the
discussion around patch 2 settles, so I haven't picked the series yet.
Lee please let me know - I can take 1/3/4 and wait for the new 2 as well.
Thanks,
Ohad.