Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1702646 > unrolled thread

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

Started byBjorn Andersson <bjorn.andersson@linaro.org>
First post2017-08-03 05:00 +0200
Last post2017-08-11 12:10 +0200
Articles 5 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v2 0/5] Qualcomm remote filesystem shared memory driver Bjorn Andersson <bjorn.andersson@linaro.org> - 2017-08-03 05:00 +0200
    [PATCH v2 4/5] soc: qcom: Remote FS memory driver Bjorn Andersson <bjorn.andersson@linaro.org> - 2017-08-03 05:00 +0200
      Re: [PATCH v2 4/5] soc: qcom: Remote FS memory driver Christoph Hellwig <hch@infradead.org> - 2017-08-05 12:00 +0200
        Re: [PATCH v2 4/5] soc: qcom: Remote FS memory driver Bjorn Andersson <bjorn.andersson@linaro.org> - 2017-08-07 18:30 +0200
          Re: [PATCH v2 4/5] soc: qcom: Remote FS memory driver Christoph Hellwig <hch@infradead.org> - 2017-08-11 12:10 +0200

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

FromBjorn Andersson <bjorn.andersson@linaro.org>
Date2017-08-03 05:00 +0200
Subject[PATCH v2 0/5] Qualcomm remote filesystem shared memory driver
Message-ID<uaewF-224-7@gated-at.bofh.it>
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

[toc] | [next] | [standalone]


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

FromBjorn Andersson <bjorn.andersson@linaro.org>
Date2017-08-03 05:00 +0200
Subject[PATCH v2 4/5] soc: qcom: Remote FS memory driver
Message-ID<uaewH-224-31@gated-at.bofh.it>
In reply to#1702646
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

[toc] | [prev] | [next] | [standalone]


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

FromChristoph Hellwig <hch@infradead.org>
Date2017-08-05 12:00 +0200
SubjectRe: [PATCH v2 4/5] soc: qcom: Remote FS memory driver
Message-ID<ub42d-3iq-3@gated-at.bofh.it>
In reply to#1702648
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.

[toc] | [prev] | [next] | [standalone]


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

FromBjorn Andersson <bjorn.andersson@linaro.org>
Date2017-08-07 18:30 +0200
SubjectRe: [PATCH v2 4/5] soc: qcom: Remote FS memory driver
Message-ID<ubT4L-2E7-45@gated-at.bofh.it>
In reply to#1704614
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

[toc] | [prev] | [next] | [standalone]


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

FromChristoph Hellwig <hch@infradead.org>
Date2017-08-11 12:10 +0200
SubjectRe: [PATCH v2 4/5] soc: qcom: Remote FS memory driver
Message-ID<udf3c-2bo-1@gated-at.bofh.it>
In reply to#1705696
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.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web