[PATCH v2 0/5] Qualcomm remote filesystem shared memory driver

[PATCH v2 0/5] Qualcomm remote filesystem shared memory driver

[Bjorn Andersson]

Some remote processors (in particular the modem) found in Qualcomm platforms
stores configuration parameters and other data in a file system. As the remotes
does not have direct storage access it needs to relay block accesses through a
service running on the application CPU.

The memory is described in DeviceTree by a new reserved-memory compatible and
the implementation provides the user space service a read/write interface to
this chunk of memory.

Bjorn Andersson (5):
  of/platform: Generalize /reserved-memory handling
  of: reserved_mem: Accessor for acquiring reserved_mem
  dt-binding: soc: qcom: Add binding for RFSA
  soc: qcom: Remote FS memory driver
  arm64: dts: msm8916: Mark rmtfs node as qcom,rfsa compatible

 .../bindings/reserved-memory/qcom,rfsa.txt         |  44 ++++
 arch/arm64/boot/dts/qcom/msm8916.dtsi              |   3 +
 drivers/of/of_reserved_mem.c                       |  26 ++
 drivers/of/platform.c                              |  22 +-
 drivers/soc/qcom/Kconfig                           |   8 +
 drivers/soc/qcom/Makefile                          |   1 +
 drivers/soc/qcom/rfsa.c                            | 262 +++++++++++++++++++++
 include/linux/of_reserved_mem.h                    |   5 +
 8 files changed, 365 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/qcom,rfsa.txt
 create mode 100644 drivers/soc/qcom/rfsa.c

-- 
2.12.0

[PATCH v2 1/5] of/platform: Generalize /reserved-memory handling

[Bjorn Andersson]

By iterating over all /reserved-memory child nodes and match each one to
a list of compatibles that we want to treat specially, we can easily
extend the list of compatibles to handle - without having to resort to
of_platform_populate() that would create unnecessary platform_devices.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v1:
- New patch

 drivers/of/platform.c | 21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b19524623498..8c241a116b08 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -497,23 +497,32 @@ int of_platform_default_populate(struct device_node *root,
 EXPORT_SYMBOL_GPL(of_platform_default_populate);
 
 #ifndef CONFIG_PPC
+static const char *rmem_compats[] = {
+	"ramoops",
+	NULL
+};
+
 static int __init of_platform_default_populate_init(void)
 {
+	struct device_node *rmem_nodes;
 	struct device_node *node;
+	int ret;
 
 	if (!of_have_populated_dt())
 		return -ENODEV;
 
 	/*
-	 * Handle ramoops explicitly, since it is inside /reserved-memory,
-	 * which lacks a "compatible" property.
+	 * Handle certain compatibles explicitly, since we don't want to create
+	 * platform_devices for every node in /reserved-memory with a
+	 * "compatible",
 	 */
-	node = of_find_node_by_path("/reserved-memory");
-	if (node) {
-		node = of_find_compatible_node(node, NULL, "ramoops");
-		if (node)
+	rmem_nodes = of_find_node_by_path("/reserved-memory");
+	for_each_available_child_of_node(rmem_nodes, node) {
+		ret = of_device_compatible_match(node, rmem_compats);
+		if (ret)
 			of_platform_device_create(node, NULL, NULL);
 	}
+	of_node_put(rmem_nodes);
 
 	/* Populate everything else. */
 	of_platform_default_populate(NULL, NULL, NULL);
-- 
2.12.0

[PATCH v2 2/5] of: reserved_mem: Accessor for acquiring reserved_mem

[Bjorn Andersson]

In some cases drivers referencing a reserved-memory region might want to
remap the entire region, but when defining the reserved-memory by "size"
the client driver has no means to know the associated base address of
the reserved memory region.

This patch adds an accessor for such drivers to acquire a handle to
their associated reserved-memory for this purpose.

A complicating factor for the implementation is that the reserved_mem
objects are created from the flattened DeviceTree, as such we can't
use the device_node address for comparison. Fortunately the name of the
node will be used as "name" of the reserved_mem and will be used when
building the full_name, so we can compare the "name" with the basename
of the full_name to find the match.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v1:
- Previous patch provided interface to resolve memory-region reference, instead
  of direct lookup by device_node

 drivers/of/of_reserved_mem.c    | 26 ++++++++++++++++++++++++++
 include/linux/of_reserved_mem.h |  5 +++++
 2 files changed, 31 insertions(+)

diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index d507c3569a88..b40cfce68fd4 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -397,3 +397,29 @@ void of_reserved_mem_device_release(struct device *dev)
 	rmem->ops->device_release(rmem, dev);
 }
 EXPORT_SYMBOL_GPL(of_reserved_mem_device_release);
+
+/**
+ * of_reserved_mem_get() - acquire reserved_mem from a device node
+ * @np:		node pointer of the desired reserved-memory region
+ *
+ * This function allows drivers to acquire a reference to the reserved_mem
+ * struct based on a device node handle.
+ *
+ * Returns a reserved_mem reference, or NULL on error.
+ */
+struct reserved_mem *of_reserved_mem_get(struct device_node *np)
+{
+	const char *name;
+	int i;
+
+	if (!np->full_name)
+		return NULL;
+
+	name = kbasename(np->full_name);
+	for (i = 0; i < reserved_mem_count; i++)
+		if (!strcmp(reserved_mem[i].name, name))
+			return &reserved_mem[i];
+
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(of_reserved_mem_get);
diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
index f8e1992d6423..91b1eb5076e4 100644
--- a/include/linux/of_reserved_mem.h
+++ b/include/linux/of_reserved_mem.h
@@ -44,6 +44,7 @@ int early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
 void fdt_init_reserved_mem(void);
 void fdt_reserved_mem_save_node(unsigned long node, const char *uname,
 			       phys_addr_t base, phys_addr_t size);
+struct reserved_mem *of_reserved_mem_get(struct device_node *np);
 #else
 static inline int of_reserved_mem_device_init_by_idx(struct device *dev,
 					struct device_node *np, int idx)
@@ -55,6 +56,10 @@ static inline void of_reserved_mem_device_release(struct device *pdev) { }
 static inline void fdt_init_reserved_mem(void) { }
 static inline void fdt_reserved_mem_save_node(unsigned long node,
 		const char *uname, phys_addr_t base, phys_addr_t size) { }
+static inline struct reserved_mem *of_reserved_mem_get(struct device_node *np)
+{
+	return NULL;
+}
 #endif
 
 /**
-- 
2.12.0

[PATCH v2 3/5] dt-binding: soc: qcom: Add binding for RFSA

[Bjorn Andersson]

This adds the binding for describing shared memory used to exchange file
system blocks between the RMTFS client and service.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changed since v1:
- Memory described in a single reserved-memory node, rather than by reference
  from a "dummy" node
- qcom,vmdid added

 .../bindings/reserved-memory/qcom,rfsa.txt         | 51 ++++++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/qcom,rfsa.txt

diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rfsa.txt b/Documentation/devicetree/bindings/reserved-memory/qcom,rfsa.txt
new file mode 100644
index 000000000000..d9bec8eec696
--- /dev/null
+++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rfsa.txt
@@ -0,0 +1,51 @@
+Qualcomm Remote File System Access binding
+
+This binding describes the Qualcomm RFSA, which serves the purpose of
+describing the shared memory region used for remote processors to access block
+device data using the Remote Filesystem protocol.
+
+- compatible:
+	Usage: required
+	Value type: <stringlist>
+	Definition: must be:
+		    "qcom,rfsa"
+
+- reg:
+	Usage: required for static allocation
+	Value type: <prop-encoded-array>
+	Definition: must specify base address and size of the memory region,
+		    as described in reserved-memory.txt
+
+- size:
+	Usage: required for dynamic allocation
+	Value type: <prop-encoded-array>
+	Definition: must specify a size of the memory region, as described in
+		    reserved-memory.txt
+
+- qcom,client-id:
+	Usage: required
+	Value type: <u32>
+	Definition: identifier of the client to use this region for buffers.
+
+- qcom,vmid:
+	Usage: optional
+	Value type: <u32>
+	Definition: vmid of the remote processor, to set up memory protection.
+
+= EXAMPLE
+The following example shows the RFSA setup for APQ8016, with the RFSA region
+for the Hexagon DSP (id #1) located at 0x86700000.
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		rmtfs@86700000 {
+			compatible = "qcom,rfsa";
+			reg = <0x0 0x86700000 0x0 0xe0000>;
+			no-map;
+
+			qcom,client-id = <1>;
+		};
+	};
-- 
2.12.0

[PATCH v2 4/5] soc: qcom: Remote FS memory driver

[Bjorn Andersson]

The rfsa driver is used for allocating and exposing regions of shared
memory with remote processors for the purpose of exchanging sector-data
between the remote filesystem service and its clients.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v1:
- RFSA device represented direclty by the reserved-memory node

 drivers/of/platform.c     |   1 +
 drivers/soc/qcom/Kconfig  |   8 ++
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/rfsa.c   | 262 ++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 272 insertions(+)
 create mode 100644 drivers/soc/qcom/rfsa.c

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 8c241a116b08..0356f31b07db 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -498,6 +498,7 @@ EXPORT_SYMBOL_GPL(of_platform_default_populate);
 
 #ifndef CONFIG_PPC
 static const char *rmem_compats[] = {
+	"qcom,rfsa",
 	"ramoops",
 	NULL
 };
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 9fca977ef18d..788a63cd430e 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -24,6 +24,14 @@ config QCOM_PM
 	  modes. It interface with various system drivers to put the cores in
 	  low power modes.
 
+config QCOM_RFSA
+	tristate "Qualcomm Remote Filesystem Access driver"
+	help
+	  The Qualcomm remote filesystem access driver is used for allocating
+	  and exposing regions of shared memory with remote processors for the
+	  purpose of exchanging sector-data between the remote filesystem
+	  service and its clients.
+
 config QCOM_SMEM
 	tristate "Qualcomm Shared Memory Manager (SMEM)"
 	depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 414f0de274fa..d1bbc791ddc0 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,6 +1,7 @@
 obj-$(CONFIG_QCOM_GSBI)	+=	qcom_gsbi.o
 obj-$(CONFIG_QCOM_MDT_LOADER)	+= mdt_loader.o
 obj-$(CONFIG_QCOM_PM)	+=	spm.o
+obj-$(CONFIG_QCOM_RFSA)	+=	rfsa.o
 obj-$(CONFIG_QCOM_SMD_RPM)	+= smd-rpm.o
 obj-$(CONFIG_QCOM_SMEM) +=	smem.o
 obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
diff --git a/drivers/soc/qcom/rfsa.c b/drivers/soc/qcom/rfsa.c
new file mode 100644
index 000000000000..1b9ec33cde48
--- /dev/null
+++ b/drivers/soc/qcom/rfsa.c
@@ -0,0 +1,262 @@
+/*
+ * Copyright (c) 2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/cdev.h>
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/of_fdt.h>
+#include <linux/dma-mapping.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/io.h>
+#include <linux/qcom_scm.h>
+
+#define QCOM_RFSA_DEV_MAX	(MINORMASK + 1)
+
+static dev_t qcom_rfsa_major;
+
+struct qcom_rfsa {
+	struct device dev;
+	struct cdev cdev;
+
+	void *base;
+	phys_addr_t addr;
+	phys_addr_t size;
+
+	unsigned int client_id;
+};
+
+static ssize_t qcom_rfsa_show(struct device *dev,
+			      struct device_attribute *attr,
+			      char *buf);
+
+static DEVICE_ATTR(phys_addr, 0400, qcom_rfsa_show, NULL);
+static DEVICE_ATTR(size, 0400, qcom_rfsa_show, NULL);
+static DEVICE_ATTR(client_id, 0400, qcom_rfsa_show, NULL);
+
+static ssize_t qcom_rfsa_show(struct device *dev,
+			      struct device_attribute *attr,
+			      char *buf)
+{
+	struct qcom_rfsa *rfsa = container_of(dev, struct qcom_rfsa, dev);
+
+	if (attr == &dev_attr_phys_addr)
+		return sprintf(buf, "%pa\n", &rfsa->addr);
+	if (attr == &dev_attr_size)
+		return sprintf(buf, "%pa\n", &rfsa->size);
+	if (attr == &dev_attr_client_id)
+		return sprintf(buf, "%d\n", rfsa->client_id);
+
+	return -EINVAL;
+}
+
+static struct attribute *qcom_rfsa_attrs[] = {
+	&dev_attr_phys_addr.attr,
+	&dev_attr_size.attr,
+	&dev_attr_client_id.attr,
+	NULL
+};
+ATTRIBUTE_GROUPS(qcom_rfsa);
+
+static int qcom_rfsa_open(struct inode *inode, struct file *filp)
+{
+	struct qcom_rfsa *rfsa = container_of(inode->i_cdev, struct qcom_rfsa, cdev);
+
+	get_device(&rfsa->dev);
+	filp->private_data = rfsa;
+
+	return 0;
+}
+static ssize_t qcom_rfsa_read(struct file *filp,
+			      char __user *buf, size_t count, loff_t *f_pos)
+{
+	struct qcom_rfsa *rfsa = filp->private_data;
+
+	if (*f_pos >= rfsa->size)
+		return 0;
+
+	if (*f_pos + count >= rfsa->size)
+		count = rfsa->size - *f_pos;
+
+	if (copy_to_user(buf, rfsa->base + *f_pos, count))
+		return -EFAULT;
+
+	*f_pos += count;
+	return count;
+}
+
+static ssize_t qcom_rfsa_write(struct file *filp,
+			       const char __user *buf, size_t count,
+			       loff_t *f_pos)
+{
+	struct qcom_rfsa *rfsa = filp->private_data;
+
+	if (*f_pos >= rfsa->size)
+		return 0;
+
+	if (*f_pos + count >= rfsa->size)
+		count = rfsa->size - *f_pos;
+
+	if (copy_from_user(rfsa->base + *f_pos, buf, count))
+		return -EFAULT;
+
+	*f_pos += count;
+	return count;
+}
+
+static int qcom_rfsa_release(struct inode *inode, struct file *filp)
+{
+	struct qcom_rfsa *rfsa = filp->private_data;
+
+	put_device(&rfsa->dev);
+
+	return 0;
+}
+
+static const struct file_operations qcom_rfsa_fops = {
+	.owner = THIS_MODULE,
+	.open = qcom_rfsa_open,
+	.read = qcom_rfsa_read,
+	.write = qcom_rfsa_write,
+	.release = qcom_rfsa_release,
+	.llseek = default_llseek,
+};
+
+static void qcom_rfsa_release_device(struct device *dev)
+{
+	struct qcom_rfsa *rfsa = container_of(dev, struct qcom_rfsa, dev);
+
+	kfree(rfsa);
+}
+
+static int qcom_rfsa_probe(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	struct reserved_mem *rmem;
+	struct qcom_rfsa *rfsa;
+	u32 client_id;
+	int ret;
+
+	rmem = of_reserved_mem_get(node);
+	if (!rmem) {
+		dev_err(&pdev->dev, "failed to acquire memory region\n");
+		return -EINVAL;
+	}
+
+	ret = of_property_read_u32(node, "qcom,client-id", &client_id);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to parse \"qcom,client-id\"\n");
+		return ret;
+
+	}
+
+	rfsa = kzalloc(sizeof(*rfsa), GFP_KERNEL);
+	if (!rfsa)
+		return -ENOMEM;
+
+	rfsa->addr = rmem->base;
+	rfsa->client_id = client_id;
+	rfsa->size = rmem->size;
+
+	device_initialize(&rfsa->dev);
+	rfsa->dev.parent = &pdev->dev;
+	rfsa->dev.groups = qcom_rfsa_groups;
+
+	cdev_init(&rfsa->cdev, &qcom_rfsa_fops);
+	rfsa->cdev.owner = THIS_MODULE;
+
+	dev_set_name(&rfsa->dev, "qcom_rfsa%d", client_id);
+	rfsa->dev.id = client_id;
+	rfsa->dev.devt = MKDEV(MAJOR(qcom_rfsa_major), client_id);
+
+	ret = cdev_device_add(&rfsa->cdev, &rfsa->dev);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to add cdev: %d\n", ret);
+		put_device(&rfsa->dev);
+		return ret;
+	}
+
+	rfsa->dev.release = qcom_rfsa_release_device;
+
+	rfsa->base = devm_memremap(&rfsa->dev, rfsa->addr, rfsa->size, MEMREMAP_WC);
+	if (IS_ERR(rfsa->base)) {
+		dev_err(&pdev->dev, "failed to remap rfsa region\n");
+
+		device_del(&rfsa->dev);
+		put_device(&rfsa->dev);
+
+		return PTR_ERR(rfsa->base);
+	}
+
+	dev_set_drvdata(&pdev->dev, rfsa);
+
+	return 0;
+}
+
+static int qcom_rfsa_remove(struct platform_device *pdev)
+{
+	struct qcom_rfsa *rfsa = dev_get_drvdata(&pdev->dev);
+
+	cdev_del(&rfsa->cdev);
+	device_del(&rfsa->dev);
+	put_device(&rfsa->dev);
+
+	return 0;
+}
+
+static const struct of_device_id qcom_rfsa_of_match[] = {
+	{ .compatible = "qcom,rfsa" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, qcom_rfsa_of_match);
+
+static struct platform_driver qcom_rfsa_driver = {
+	.probe = qcom_rfsa_probe,
+	.remove = qcom_rfsa_remove,
+	.driver  = {
+		.name  = "qcom_rfsa",
+		.of_match_table = qcom_rfsa_of_match,
+	},
+};
+
+static int qcom_rfsa_init(void)
+{
+	int ret;
+
+	ret = alloc_chrdev_region(&qcom_rfsa_major, 0, QCOM_RFSA_DEV_MAX,
+				  "qcom_rfsa");
+	if (ret < 0) {
+		pr_err("qcom_rfsa: failed to allocate char dev region\n");
+		return ret;
+	}
+
+	ret = platform_driver_register(&qcom_rfsa_driver);
+	if (ret < 0) {
+		pr_err("qcom_rfsa: failed to register rfsa driver\n");
+		unregister_chrdev_region(qcom_rfsa_major, QCOM_RFSA_DEV_MAX);
+	}
+
+	return ret;
+}
+module_init(qcom_rfsa_init);
+
+static void qcom_rfsa_exit(void)
+{
+	platform_driver_unregister(&qcom_rfsa_driver);
+	unregister_chrdev_region(qcom_rfsa_major, QCOM_RFSA_DEV_MAX);
+}
+module_exit(qcom_rfsa_exit);
-- 
2.12.0

[PATCH v2 5/5] arm64: dts: msm8916: Mark rmtfs node as qcom,rfsa compatible

[Bjorn Andersson]

Now that we have a binding defined for the shared file system memory use
this to describe the rmtfs memory region.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v1:
- New patch

 arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 039991f80831..9d364297df3a 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -69,8 +69,11 @@
 		};
 
 		rmtfs@86700000 {
+			compatible = "qcom,rfsa";
 			reg = <0x0 0x86700000 0x0 0xe0000>;
 			no-map;
+
+			qcom,client-id = <1>;
 		};
 
 		rfsa@867e00000 {
-- 
2.12.0

Re: [PATCH v2 1/5] of/platform: Generalize /reserved-memory handling

[Rob Herring]

On Wed, Aug 2, 2017 at 9:57 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> By iterating over all /reserved-memory child nodes and match each one to
> a list of compatibles that we want to treat specially, we can easily
> extend the list of compatibles to handle - without having to resort to
> of_platform_populate() that would create unnecessary platform_devices.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Changes since v1:
> - New patch
>
>  drivers/of/platform.c | 21 +++++++++++++++------
>  1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index b19524623498..8c241a116b08 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -497,23 +497,32 @@ int of_platform_default_populate(struct device_node *root,
>  EXPORT_SYMBOL_GPL(of_platform_default_populate);
>
>  #ifndef CONFIG_PPC
> +static const char *rmem_compats[] = {
> +       "ramoops",
> +       NULL
> +};
> +
>  static int __init of_platform_default_populate_init(void)
>  {
> +       struct device_node *rmem_nodes;
>         struct device_node *node;
> +       int ret;
>
>         if (!of_have_populated_dt())
>                 return -ENODEV;
>
>         /*
> -        * Handle ramoops explicitly, since it is inside /reserved-memory,
> -        * which lacks a "compatible" property.
> +        * Handle certain compatibles explicitly, since we don't want to create
> +        * platform_devices for every node in /reserved-memory with a
> +        * "compatible",
>          */
> -       node = of_find_node_by_path("/reserved-memory");
> -       if (node) {
> -               node = of_find_compatible_node(node, NULL, "ramoops");
> -               if (node)
> +       rmem_nodes = of_find_node_by_path("/reserved-memory");
> +       for_each_available_child_of_node(rmem_nodes, node) {
> +               ret = of_device_compatible_match(node, rmem_compats);
> +               if (ret)

I would just do:

for_each_matching_node(node, ...)
    of_platform_device_create(node, NULL, NULL);

I don't think the kernel has to validate that ramoops and any others
we add are children of /reserved-memory. We should only have those
compatibles located there and any other location would be an error.

>                         of_platform_device_create(node, NULL, NULL);
>         }
> +       of_node_put(rmem_nodes);
>
>         /* Populate everything else. */
>         of_platform_default_populate(NULL, NULL, NULL);
> --
> 2.12.0
>

Re: [PATCH v2 2/5] of: reserved_mem: Accessor for acquiring reserved_mem

[Rob Herring]

On Wed, Aug 2, 2017 at 9:57 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> In some cases drivers referencing a reserved-memory region might want to
> remap the entire region, but when defining the reserved-memory by "size"
> the client driver has no means to know the associated base address of
> the reserved memory region.
>
> This patch adds an accessor for such drivers to acquire a handle to
> their associated reserved-memory for this purpose.
>
> A complicating factor for the implementation is that the reserved_mem
> objects are created from the flattened DeviceTree, as such we can't
> use the device_node address for comparison. Fortunately the name of the
> node will be used as "name" of the reserved_mem and will be used when
> building the full_name, so we can compare the "name" with the basename
> of the full_name to find the match.

Maybe we should add the device_node pointer when we unflatten?

>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Changes since v1:
> - Previous patch provided interface to resolve memory-region reference, instead
>   of direct lookup by device_node
>
>  drivers/of/of_reserved_mem.c    | 26 ++++++++++++++++++++++++++
>  include/linux/of_reserved_mem.h |  5 +++++
>  2 files changed, 31 insertions(+)
>
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> index d507c3569a88..b40cfce68fd4 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -397,3 +397,29 @@ void of_reserved_mem_device_release(struct device *dev)
>         rmem->ops->device_release(rmem, dev);
>  }
>  EXPORT_SYMBOL_GPL(of_reserved_mem_device_release);
> +
> +/**
> + * of_reserved_mem_get() - acquire reserved_mem from a device node
> + * @np:                node pointer of the desired reserved-memory region
> + *
> + * This function allows drivers to acquire a reference to the reserved_mem
> + * struct based on a device node handle.
> + *
> + * Returns a reserved_mem reference, or NULL on error.
> + */
> +struct reserved_mem *of_reserved_mem_get(struct device_node *np)
> +{
> +       const char *name;
> +       int i;
> +
> +       if (!np->full_name)
> +               return NULL;
> +
> +       name = kbasename(np->full_name);
> +       for (i = 0; i < reserved_mem_count; i++)
> +               if (!strcmp(reserved_mem[i].name, name))
> +                       return &reserved_mem[i];
> +
> +       return NULL;
> +}
> +EXPORT_SYMBOL_GPL(of_reserved_mem_get);
> diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
> index f8e1992d6423..91b1eb5076e4 100644
> --- a/include/linux/of_reserved_mem.h
> +++ b/include/linux/of_reserved_mem.h
> @@ -44,6 +44,7 @@ int early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
>  void fdt_init_reserved_mem(void);
>  void fdt_reserved_mem_save_node(unsigned long node, const char *uname,
>                                phys_addr_t base, phys_addr_t size);
> +struct reserved_mem *of_reserved_mem_get(struct device_node *np);
>  #else
>  static inline int of_reserved_mem_device_init_by_idx(struct device *dev,
>                                         struct device_node *np, int idx)
> @@ -55,6 +56,10 @@ static inline void of_reserved_mem_device_release(struct device *pdev) { }
>  static inline void fdt_init_reserved_mem(void) { }
>  static inline void fdt_reserved_mem_save_node(unsigned long node,
>                 const char *uname, phys_addr_t base, phys_addr_t size) { }
> +static inline struct reserved_mem *of_reserved_mem_get(struct device_node *np)
> +{
> +       return NULL;
> +}
>  #endif
>
>  /**
> --
> 2.12.0
>

Re: [PATCH v2 2/5] of: reserved_mem: Accessor for acquiring reserved_mem

[Bjorn Andersson]

On Thu 03 Aug 10:45 PDT 2017, Rob Herring wrote:

> On Wed, Aug 2, 2017 at 9:57 PM, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> > In some cases drivers referencing a reserved-memory region might want to
> > remap the entire region, but when defining the reserved-memory by "size"
> > the client driver has no means to know the associated base address of
> > the reserved memory region.
> >
> > This patch adds an accessor for such drivers to acquire a handle to
> > their associated reserved-memory for this purpose.
> >
> > A complicating factor for the implementation is that the reserved_mem
> > objects are created from the flattened DeviceTree, as such we can't
> > use the device_node address for comparison. Fortunately the name of the
> > node will be used as "name" of the reserved_mem and will be used when
> > building the full_name, so we can compare the "name" with the basename
> > of the full_name to find the match.
> 
> Maybe we should add the device_node pointer when we unflatten?
> 

It did try to figure something sane out in that direction.

The solution I came up with was to amend populate_node() to in a !dryrun
block check if the "dad" full_name is /reserved-memory and if so
call call a new accessor in of_reserved_mem.c to add the "np" to the
reserved_mem object with fdt_node equal offset.

This code path is already cluttered due to the version differences when
it comes to building full_name and we would end up checking for each
node in the entire tree if the parent happens to be "/reserved-mem".

So I went for the less intrusive and more straight forward comparison
with basename(full_name) instead.


Do you have any alternative suggestion of how to do this?

Regards,
Bjorn

Re: [PATCH v2 1/5] of/platform: Generalize /reserved-memory handling

[Bjorn Andersson]

On Thu 03 Aug 10:40 PDT 2017, Rob Herring wrote:

> On Wed, Aug 2, 2017 at 9:57 PM, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> > diff --git a/drivers/of/platform.c b/drivers/of/platform.c
[..]
> > +       rmem_nodes = of_find_node_by_path("/reserved-memory");
> > +       for_each_available_child_of_node(rmem_nodes, node) {
> > +               ret = of_device_compatible_match(node, rmem_compats);
> > +               if (ret)
> 
> I would just do:
> 
> for_each_matching_node(node, ...)
>     of_platform_device_create(node, NULL, NULL);
> 
> I don't think the kernel has to validate that ramoops and any others
> we add are children of /reserved-memory. We should only have those
> compatibles located there and any other location would be an error.
> 

Okay, looks reasonable.

Will update and resend once I know your decision on 2/5.

Regards,
Bjorn

Re: [PATCH v2 2/5] of: reserved_mem: Accessor for acquiring reserved_mem

[Rob Herring]

On Thu, Aug 3, 2017 at 6:31 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Thu 03 Aug 10:45 PDT 2017, Rob Herring wrote:
>
>> On Wed, Aug 2, 2017 at 9:57 PM, Bjorn Andersson
>> <bjorn.andersson@linaro.org> wrote:
>> > In some cases drivers referencing a reserved-memory region might want to
>> > remap the entire region, but when defining the reserved-memory by "size"
>> > the client driver has no means to know the associated base address of
>> > the reserved memory region.
>> >
>> > This patch adds an accessor for such drivers to acquire a handle to
>> > their associated reserved-memory for this purpose.
>> >
>> > A complicating factor for the implementation is that the reserved_mem
>> > objects are created from the flattened DeviceTree, as such we can't
>> > use the device_node address for comparison. Fortunately the name of the
>> > node will be used as "name" of the reserved_mem and will be used when
>> > building the full_name, so we can compare the "name" with the basename
>> > of the full_name to find the match.
>>
>> Maybe we should add the device_node pointer when we unflatten?
>>
>
> It did try to figure something sane out in that direction.
>
> The solution I came up with was to amend populate_node() to in a !dryrun
> block check if the "dad" full_name is /reserved-memory and if so
> call call a new accessor in of_reserved_mem.c to add the "np" to the
> reserved_mem object with fdt_node equal offset.

I was thinking doing it with the unflattened tree just after it has
been unflattened rather than during unflattening.

> This code path is already cluttered due to the version differences when
> it comes to building full_name and we would end up checking for each
> node in the entire tree if the parent happens to be "/reserved-mem".
>
> So I went for the less intrusive and more straight forward comparison
> with basename(full_name) instead.

That's good, because full_name is about to become just the basename.

Rob

Re: [PATCH v2 2/5] of: reserved_mem: Accessor for acquiring reserved_mem

[Bjorn Andersson]

On Fri 04 Aug 07:50 PDT 2017, Rob Herring wrote:

> On Thu, Aug 3, 2017 at 6:31 PM, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> > On Thu 03 Aug 10:45 PDT 2017, Rob Herring wrote:
> >
> >> On Wed, Aug 2, 2017 at 9:57 PM, Bjorn Andersson
> >> <bjorn.andersson@linaro.org> wrote:
> >> > In some cases drivers referencing a reserved-memory region might want to
> >> > remap the entire region, but when defining the reserved-memory by "size"
> >> > the client driver has no means to know the associated base address of
> >> > the reserved memory region.
> >> >
> >> > This patch adds an accessor for such drivers to acquire a handle to
> >> > their associated reserved-memory for this purpose.
> >> >
> >> > A complicating factor for the implementation is that the reserved_mem
> >> > objects are created from the flattened DeviceTree, as such we can't
> >> > use the device_node address for comparison. Fortunately the name of the
> >> > node will be used as "name" of the reserved_mem and will be used when
> >> > building the full_name, so we can compare the "name" with the basename
> >> > of the full_name to find the match.
> >>
> >> Maybe we should add the device_node pointer when we unflatten?
> >>
> >
> > It did try to figure something sane out in that direction.
> >
> > The solution I came up with was to amend populate_node() to in a !dryrun
> > block check if the "dad" full_name is /reserved-memory and if so
> > call call a new accessor in of_reserved_mem.c to add the "np" to the
> > reserved_mem object with fdt_node equal offset.
> 
> I was thinking doing it with the unflattened tree just after it has
> been unflattened rather than during unflattening.
> 

The problem is that the fdt_node of the reserved_mem is the offset in
the flat tree, but we don't carry this information with us when we
create the individual device_nodes.

So, AFAICT, to fill out this information at any point after returning
from the particular populate_node() call we will have to use some sort
of heuristics in matching the two nodes.

> > This code path is already cluttered due to the version differences when
> > it comes to building full_name and we would end up checking for each
> > node in the entire tree if the parent happens to be "/reserved-mem".
> >
> > So I went for the less intrusive and more straight forward comparison
> > with basename(full_name) instead.
> 
> That's good, because full_name is about to become just the basename.
> 

I'll update patch 1/5 and resend the series.

Thanks,
Bjorn

Re: [PATCH v2 4/5] soc: qcom: Remote FS memory driver

[Christoph Hellwig]

On Wed, Aug 02, 2017 at 07:57:53PM -0700, Bjorn Andersson wrote:
> The rfsa driver is used for allocating and exposing regions of shared
> memory with remote processors for the purpose of exchanging sector-data
> between the remote filesystem service and its clients.

Please explain which remote fs this is for, and submit said file system
for incluѕion.

Else: NAK as the scheme looks completely brain dead and bonkers.

Re: [PATCH v2 4/5] soc: qcom: Remote FS memory driver

[Bjorn Andersson]

On Sat 05 Aug 02:58 PDT 2017, Christoph Hellwig wrote:

> On Wed, Aug 02, 2017 at 07:57:53PM -0700, Bjorn Andersson wrote:
> > The rfsa driver is used for allocating and exposing regions of shared
> > memory with remote processors for the purpose of exchanging sector-data
> > between the remote filesystem service and its clients.
> 
> Please explain which remote fs this is for, and submit said file system
> for inclu??ion.
> 

In the NAND-era of Qualcomm platforms the modem firmware had direct
access to the storage media, but with the move to eMMC and the
transition of Linux/Android to become the "primary OS" this access was
lost.

Remaining in the modem firmware is a file system (EFS) for parameter
storage et al, but the block layer was replaced with a block-access
protocol, "conveniently" called RemoteFS.

The protocol is based on a chunk of RAM and a set of messages to
transfer sector-data between the storage device and the chunk of RAM.


Up until this patch the user space tool that implements the message
handler just mapped the reserved memory region though /dev/mem, but this
requires /dev/mem access and for the later platforms we need to make a
call into TrustZone to provide the remote permission to access this
memory region. So we need some code in the kernel to represent this.

> Else: NAK as the scheme looks completely brain dead and bonkers.

I can rework the commit message in an attempt to better explain the
setup and hope you/people find it slightly less bonkers.

Does this sound reasonable?

Regards,
Bjorn

Re: [PATCH v2 3/5] dt-binding: soc: qcom: Add binding for RFSA

[Rob Herring]

On Wed, Aug 02, 2017 at 07:57:52PM -0700, Bjorn Andersson wrote:
> This adds the binding for describing shared memory used to exchange file
> system blocks between the RMTFS client and service.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Changed since v1:
> - Memory described in a single reserved-memory node, rather than by reference
>   from a "dummy" node
> - qcom,vmdid added
> 
>  .../bindings/reserved-memory/qcom,rfsa.txt         | 51 ++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reserved-memory/qcom,rfsa.txt

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH v2 4/5] soc: qcom: Remote FS memory driver

[Christoph Hellwig]

On Mon, Aug 07, 2017 at 09:23:27AM -0700, Bjorn Andersson wrote:
> Up until this patch the user space tool that implements the message
> handler just mapped the reserved memory region though /dev/mem, but this
> requires /dev/mem access and for the later platforms we need to make a
> call into TrustZone to provide the remote permission to access this
> memory region. So we need some code in the kernel to represent this.
> 
> > Else: NAK as the scheme looks completely brain dead and bonkers.
> 
> I can rework the commit message in an attempt to better explain the
> setup and hope you/people find it slightly less bonkers.
> 
> Does this sound reasonable?

Please rework the commit message.  And it should probably grow a saner
module name, too.