linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/3] fs: add partial file read support
@ 2019-05-23  2:51 Scott Branden
  2019-05-23  2:51 ` [PATCH 1/3] fs: introduce kernel_pread_file* support Scott Branden
                   ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Scott Branden @ 2019-05-23  2:51 UTC (permalink / raw)
  To: Luis Chamberlain, Greg Kroah-Hartman, Andy Gross, David Brown,
	Alexander Viro
  Cc: Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Scott Branden

This patch series adds partial file read support to the kernel via
kernel_pread_file functions.  request_firmware_into_buf function
enhanced to allow partial file read support and single qcom driver
using existing function updated.
Change to core kernel file support allows new drivers to read partial
file to memory as necessary in memory constrained systems.

Scott Branden (3):
  fs: introduce kernel_pread_file* support
  firmware: add offset to request_firmware_into_buf
  soc: qcom: mdt_loader: add offset to request_firmware_into_buf

 drivers/base/firmware_loader/firmware.h |  5 ++
 drivers/base/firmware_loader/main.c     | 49 +++++++++++-----
 drivers/soc/qcom/mdt_loader.c           |  7 ++-
 fs/exec.c                               | 77 +++++++++++++++++++------
 include/linux/firmware.h                |  8 ++-
 include/linux/fs.h                      | 15 +++++
 6 files changed, 125 insertions(+), 36 deletions(-)

-- 
2.17.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 1/3] fs: introduce kernel_pread_file* support
  2019-05-23  2:51 [PATCH 0/3] fs: add partial file read support Scott Branden
@ 2019-05-23  2:51 ` Scott Branden
  2019-05-23  2:51 ` [PATCH 2/3] firmware: add offset to request_firmware_into_buf Scott Branden
  2019-05-23  2:51 ` [PATCH 3/3] soc: qcom: mdt_loader: " Scott Branden
  2 siblings, 0 replies; 20+ messages in thread
From: Scott Branden @ 2019-05-23  2:51 UTC (permalink / raw)
  To: Luis Chamberlain, Greg Kroah-Hartman, Andy Gross, David Brown,
	Alexander Viro
  Cc: Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Scott Branden

Add kernel_pread_file* support to kernel to allow for partial read
of files with an offset into the file.  Existing kernel_read_file
functions call new kernel_pread_file functions with offset=0 and
flags=KERNEL_PREAD_FLAG_WHOLE.

Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
 fs/exec.c          | 77 ++++++++++++++++++++++++++++++++++++----------
 include/linux/fs.h | 15 +++++++++
 2 files changed, 75 insertions(+), 17 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index d88584ebf07f..ba56450acfb3 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -892,10 +892,14 @@ struct file *open_exec(const char *name)
 }
 EXPORT_SYMBOL(open_exec);
 
-int kernel_read_file(struct file *file, void **buf, loff_t *size,
-		     loff_t max_size, enum kernel_read_file_id id)
-{
-	loff_t i_size, pos;
+int kernel_pread_file(struct file *file, void **buf, loff_t *size,
+		      loff_t pos, loff_t max_size, unsigned int flags,
+		      enum kernel_read_file_id id)
+{
+	loff_t alloc_size;
+	loff_t buf_pos;
+	loff_t read_end;
+	loff_t i_size;
 	ssize_t bytes = 0;
 	int ret;
 
@@ -915,21 +919,31 @@ int kernel_read_file(struct file *file, void **buf, loff_t *size,
 		ret = -EINVAL;
 		goto out;
 	}
-	if (i_size > SIZE_MAX || (max_size > 0 && i_size > max_size)) {
+
+	/* Default read to end of file */
+	read_end = i_size;
+
+	/* Allow reading partial portion of file */
+	if ((flags & KERNEL_PREAD_FLAG_PART) &&
+	    (i_size > (pos + max_size)))
+		read_end = pos + max_size;
+
+	alloc_size = read_end - pos;
+	if (i_size > SIZE_MAX || (max_size > 0 && alloc_size > max_size)) {
 		ret = -EFBIG;
 		goto out;
 	}
 
 	if (id != READING_FIRMWARE_PREALLOC_BUFFER)
-		*buf = vmalloc(i_size);
+		*buf = vmalloc(alloc_size);
 	if (!*buf) {
 		ret = -ENOMEM;
 		goto out;
 	}
 
-	pos = 0;
-	while (pos < i_size) {
-		bytes = kernel_read(file, *buf + pos, i_size - pos, &pos);
+	buf_pos = 0;
+	while (pos < read_end) {
+		bytes = kernel_read(file, *buf + buf_pos, read_end - pos, &pos);
 		if (bytes < 0) {
 			ret = bytes;
 			goto out_free;
@@ -937,14 +951,16 @@ int kernel_read_file(struct file *file, void **buf, loff_t *size,
 
 		if (bytes == 0)
 			break;
+
+		buf_pos += bytes;
 	}
 
-	if (pos != i_size) {
+	if (pos != read_end) {
 		ret = -EIO;
 		goto out_free;
 	}
 
-	ret = security_kernel_post_read_file(file, *buf, i_size, id);
+	ret = security_kernel_post_read_file(file, *buf, alloc_size, id);
 	if (!ret)
 		*size = pos;
 
@@ -960,10 +976,20 @@ int kernel_read_file(struct file *file, void **buf, loff_t *size,
 	allow_write_access(file);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(kernel_pread_file);
+
+int kernel_read_file(struct file *file, void **buf, loff_t *size,
+		     loff_t max_size, enum kernel_read_file_id id)
+{
+	return kernel_pread_file(file, buf, size, 0, max_size,
+				 KERNEL_PREAD_FLAG_WHOLE, id);
+}
 EXPORT_SYMBOL_GPL(kernel_read_file);
 
-int kernel_read_file_from_path(const char *path, void **buf, loff_t *size,
-			       loff_t max_size, enum kernel_read_file_id id)
+int kernel_pread_file_from_path(const char *path, void **buf,
+				loff_t *size, loff_t pos,
+				loff_t max_size, unsigned int flags,
+				enum kernel_read_file_id id)
 {
 	struct file *file;
 	int ret;
@@ -975,14 +1001,23 @@ int kernel_read_file_from_path(const char *path, void **buf, loff_t *size,
 	if (IS_ERR(file))
 		return PTR_ERR(file);
 
-	ret = kernel_read_file(file, buf, size, max_size, id);
+	ret = kernel_pread_file(file, buf, size, pos, max_size, flags, id);
 	fput(file);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(kernel_pread_file_from_path);
+
+int kernel_read_file_from_path(const char *path, void **buf, loff_t *size,
+			       loff_t max_size, enum kernel_read_file_id id)
+{
+	return kernel_pread_file_from_path(path, buf, size, 0, max_size,
+					   KERNEL_PREAD_FLAG_WHOLE, id);
+}
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path);
 
-int kernel_read_file_from_fd(int fd, void **buf, loff_t *size, loff_t max_size,
-			     enum kernel_read_file_id id)
+int kernel_pread_file_from_fd(int fd, void **buf, loff_t *size, loff_t pos,
+			      loff_t max_size, unsigned int flags,
+			      enum kernel_read_file_id id)
 {
 	struct fd f = fdget(fd);
 	int ret = -EBADF;
@@ -990,11 +1025,19 @@ int kernel_read_file_from_fd(int fd, void **buf, loff_t *size, loff_t max_size,
 	if (!f.file)
 		goto out;
 
-	ret = kernel_read_file(f.file, buf, size, max_size, id);
+	ret = kernel_pread_file(f.file, buf, size, pos, max_size, flags, id);
 out:
 	fdput(f);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(kernel_pread_file_from_fd);
+
+int kernel_read_file_from_fd(int fd, void **buf, loff_t *size, loff_t max_size,
+			     enum kernel_read_file_id id)
+{
+	return kernel_pread_file_from_fd(fd, buf, size, 0, max_size,
+					 KERNEL_PREAD_FLAG_WHOLE, id);
+}
 EXPORT_SYMBOL_GPL(kernel_read_file_from_fd);
 
 ssize_t read_code(struct file *file, unsigned long addr, loff_t pos, size_t len)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index f7fdfe93e25d..033a3e7f0015 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2942,10 +2942,25 @@ static inline const char *kernel_read_file_id_str(enum kernel_read_file_id id)
 	return kernel_read_file_str[id];
 }
 
+/* Flags used by kernel_pread_file functions */
+#define KERNEL_PREAD_FLAG_WHOLE	0x0000 /* Only Allow reading of whole file */
+#define KERNEL_PREAD_FLAG_PART	0x0001 /* Allow reading part of file */
+
+extern int kernel_pread_file(struct file *file, void **buf, loff_t *size,
+			     loff_t pos, loff_t max_size, unsigned int flags,
+			     enum kernel_read_file_id id);
 extern int kernel_read_file(struct file *, void **, loff_t *, loff_t,
 			    enum kernel_read_file_id);
+extern int kernel_pread_file_from_path(const char *path, void **buf,
+				       loff_t *size, loff_t pos,
+				       loff_t max_size, unsigned int flags,
+				       enum kernel_read_file_id id);
 extern int kernel_read_file_from_path(const char *, void **, loff_t *, loff_t,
 				      enum kernel_read_file_id);
+extern int kernel_pread_file_from_fd(int fd, void **buf, loff_t *size,
+				    loff_t pos, loff_t max_size,
+				    unsigned int flags,
+				    enum kernel_read_file_id id);
 extern int kernel_read_file_from_fd(int, void **, loff_t *, loff_t,
 				    enum kernel_read_file_id);
 extern ssize_t kernel_read(struct file *, void *, size_t, loff_t *);
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH 2/3] firmware: add offset to request_firmware_into_buf
  2019-05-23  2:51 [PATCH 0/3] fs: add partial file read support Scott Branden
  2019-05-23  2:51 ` [PATCH 1/3] fs: introduce kernel_pread_file* support Scott Branden
@ 2019-05-23  2:51 ` Scott Branden
  2019-05-23  5:52   ` Greg Kroah-Hartman
  2019-05-23  2:51 ` [PATCH 3/3] soc: qcom: mdt_loader: " Scott Branden
  2 siblings, 1 reply; 20+ messages in thread
From: Scott Branden @ 2019-05-23  2:51 UTC (permalink / raw)
  To: Luis Chamberlain, Greg Kroah-Hartman, Andy Gross, David Brown,
	Alexander Viro
  Cc: Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Scott Branden

Add offset to request_firmware_into_buf to allow for portions
of firmware file to be read into a buffer.  Necessary where firmware
needs to be loaded in portions from file in memory constrained systems.

Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
 drivers/base/firmware_loader/firmware.h |  5 +++
 drivers/base/firmware_loader/main.c     | 49 +++++++++++++++++--------
 include/linux/firmware.h                |  8 +++-
 3 files changed, 45 insertions(+), 17 deletions(-)

diff --git a/drivers/base/firmware_loader/firmware.h b/drivers/base/firmware_loader/firmware.h
index 4c1395f8e7ed..d73d400c2023 100644
--- a/drivers/base/firmware_loader/firmware.h
+++ b/drivers/base/firmware_loader/firmware.h
@@ -29,6 +29,8 @@
  *	firmware caching mechanism.
  * @FW_OPT_NOFALLBACK: Disable the fallback mechanism. Takes precedence over
  *	&FW_OPT_UEVENT and &FW_OPT_USERHELPER.
+ * @FW_OPT_PARTIAL: Allow partial read of firmware instead of needing to read
+ *	entire file.
  */
 enum fw_opt {
 	FW_OPT_UEVENT =         BIT(0),
@@ -37,6 +39,7 @@ enum fw_opt {
 	FW_OPT_NO_WARN =        BIT(3),
 	FW_OPT_NOCACHE =        BIT(4),
 	FW_OPT_NOFALLBACK =     BIT(5),
+	FW_OPT_PARTIAL =        BIT(6),
 };
 
 enum fw_status {
@@ -64,6 +67,8 @@ struct fw_priv {
 	void *data;
 	size_t size;
 	size_t allocated_size;
+	size_t offset;
+	unsigned int flags;
 #ifdef CONFIG_FW_LOADER_USER_HELPER
 	bool is_paged_buf;
 	bool need_uevent;
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index 7eaaf5ee5ba6..34d4f043b7c8 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -166,7 +166,8 @@ static int fw_cache_piggyback_on_request(const char *name);
 
 static struct fw_priv *__allocate_fw_priv(const char *fw_name,
 					  struct firmware_cache *fwc,
-					  void *dbuf, size_t size)
+					  void *dbuf, size_t size,
+					  size_t offset, unsigned int flags)
 {
 	struct fw_priv *fw_priv;
 
@@ -184,6 +185,8 @@ static struct fw_priv *__allocate_fw_priv(const char *fw_name,
 	fw_priv->fwc = fwc;
 	fw_priv->data = dbuf;
 	fw_priv->allocated_size = size;
+	fw_priv->offset = offset;
+	fw_priv->flags = flags;
 	fw_state_init(fw_priv);
 #ifdef CONFIG_FW_LOADER_USER_HELPER
 	INIT_LIST_HEAD(&fw_priv->pending_list);
@@ -209,9 +212,11 @@ static struct fw_priv *__lookup_fw_priv(const char *fw_name)
 static int alloc_lookup_fw_priv(const char *fw_name,
 				struct firmware_cache *fwc,
 				struct fw_priv **fw_priv, void *dbuf,
-				size_t size, enum fw_opt opt_flags)
+				size_t size, enum fw_opt opt_flags,
+				size_t offset)
 {
 	struct fw_priv *tmp;
+	unsigned int pread_flags;
 
 	spin_lock(&fwc->lock);
 	if (!(opt_flags & FW_OPT_NOCACHE)) {
@@ -225,7 +230,12 @@ static int alloc_lookup_fw_priv(const char *fw_name,
 		}
 	}
 
-	tmp = __allocate_fw_priv(fw_name, fwc, dbuf, size);
+	if (opt_flags & FW_OPT_PARTIAL)
+		pread_flags = KERNEL_PREAD_FLAG_PART;
+	else
+		pread_flags = KERNEL_PREAD_FLAG_WHOLE;
+
+	tmp = __allocate_fw_priv(fw_name, fwc, dbuf, size, offset, pread_flags);
 	if (tmp) {
 		INIT_LIST_HEAD(&tmp->list);
 		if (!(opt_flags & FW_OPT_NOCACHE))
@@ -325,8 +335,9 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv)
 		}
 
 		fw_priv->size = 0;
-		rc = kernel_read_file_from_path(path, &fw_priv->data, &size,
-						msize, id);
+		rc = kernel_pread_file_from_path(path, &fw_priv->data, &size,
+						 fw_priv->offset, msize,
+						 fw_priv->flags, id);
 		if (rc) {
 			if (rc != -ENOENT)
 				dev_warn(device, "loading %s failed with error %d\n",
@@ -500,7 +511,7 @@ int assign_fw(struct firmware *fw, struct device *device,
 static int
 _request_firmware_prepare(struct firmware **firmware_p, const char *name,
 			  struct device *device, void *dbuf, size_t size,
-			  enum fw_opt opt_flags)
+			  enum fw_opt opt_flags, size_t offset)
 {
 	struct firmware *firmware;
 	struct fw_priv *fw_priv;
@@ -519,7 +530,7 @@ _request_firmware_prepare(struct firmware **firmware_p, const char *name,
 	}
 
 	ret = alloc_lookup_fw_priv(name, &fw_cache, &fw_priv, dbuf, size,
-				  opt_flags);
+				  opt_flags, offset);
 
 	/*
 	 * bind with 'priv' now to avoid warning in failure path
@@ -566,7 +577,7 @@ static void fw_abort_batch_reqs(struct firmware *fw)
 static int
 _request_firmware(const struct firmware **firmware_p, const char *name,
 		  struct device *device, void *buf, size_t size,
-		  enum fw_opt opt_flags)
+		  enum fw_opt opt_flags, size_t offset)
 {
 	struct firmware *fw = NULL;
 	int ret;
@@ -580,7 +591,7 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
 	}
 
 	ret = _request_firmware_prepare(&fw, name, device, buf, size,
-					opt_flags);
+					opt_flags, offset);
 	if (ret <= 0) /* error or already assigned */
 		goto out;
 
@@ -634,7 +645,7 @@ request_firmware(const struct firmware **firmware_p, const char *name,
 	/* Need to pin this module until return */
 	__module_get(THIS_MODULE);
 	ret = _request_firmware(firmware_p, name, device, NULL, 0,
-				FW_OPT_UEVENT);
+				FW_OPT_UEVENT, 0);
 	module_put(THIS_MODULE);
 	return ret;
 }
@@ -661,7 +672,7 @@ int firmware_request_nowarn(const struct firmware **firmware, const char *name,
 	/* Need to pin this module until return */
 	__module_get(THIS_MODULE);
 	ret = _request_firmware(firmware, name, device, NULL, 0,
-				FW_OPT_UEVENT | FW_OPT_NO_WARN);
+				FW_OPT_UEVENT | FW_OPT_NO_WARN, 0);
 	module_put(THIS_MODULE);
 	return ret;
 }
@@ -686,7 +697,7 @@ int request_firmware_direct(const struct firmware **firmware_p,
 	__module_get(THIS_MODULE);
 	ret = _request_firmware(firmware_p, name, device, NULL, 0,
 				FW_OPT_UEVENT | FW_OPT_NO_WARN |
-				FW_OPT_NOFALLBACK);
+				FW_OPT_NOFALLBACK, 0);
 	module_put(THIS_MODULE);
 	return ret;
 }
@@ -723,6 +734,8 @@ EXPORT_SYMBOL_GPL(firmware_request_cache);
  * @device: device for which firmware is being loaded and DMA region allocated
  * @buf: address of buffer to load firmware into
  * @size: size of buffer
+ * @offset: offset into file to read
+ * @pread_flags: KERNEL_PREAD_FLAG_PART to allow partial file read
  *
  * This function works pretty much like request_firmware(), but it doesn't
  * allocate a buffer to hold the firmware data. Instead, the firmware
@@ -733,16 +746,22 @@ EXPORT_SYMBOL_GPL(firmware_request_cache);
  */
 int
 request_firmware_into_buf(const struct firmware **firmware_p, const char *name,
-			  struct device *device, void *buf, size_t size)
+			  struct device *device, void *buf, size_t size,
+			  size_t offset, unsigned int pread_flags)
 {
 	int ret;
+	enum fw_opt opt_flags;
 
 	if (fw_cache_is_setup(device, name))
 		return -EOPNOTSUPP;
 
 	__module_get(THIS_MODULE);
+	opt_flags = FW_OPT_UEVENT | FW_OPT_NOCACHE;
+	if (pread_flags & KERNEL_PREAD_FLAG_PART)
+		opt_flags |= FW_OPT_PARTIAL;
+
 	ret = _request_firmware(firmware_p, name, device, buf, size,
-				FW_OPT_UEVENT | FW_OPT_NOCACHE);
+				opt_flags, offset);
 	module_put(THIS_MODULE);
 	return ret;
 }
@@ -781,7 +800,7 @@ static void request_firmware_work_func(struct work_struct *work)
 	fw_work = container_of(work, struct firmware_work, work);
 
 	_request_firmware(&fw, fw_work->name, fw_work->device, NULL, 0,
-			  fw_work->opt_flags);
+			  fw_work->opt_flags, 0);
 	fw_work->cont(fw, fw_work->context);
 	put_device(fw_work->device); /* taken in request_firmware_nowait() */
 
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index 2dd566c91d44..c81162a8d709 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -4,6 +4,7 @@
 
 #include <linux/types.h>
 #include <linux/compiler.h>
+#include <linux/fs.h>
 #include <linux/gfp.h>
 
 #define FW_ACTION_NOHOTPLUG 0
@@ -51,7 +52,9 @@ int request_firmware_nowait(
 int request_firmware_direct(const struct firmware **fw, const char *name,
 			    struct device *device);
 int request_firmware_into_buf(const struct firmware **firmware_p,
-	const char *name, struct device *device, void *buf, size_t size);
+			      const char *name, struct device *device,
+			      void *buf, size_t size,
+			      size_t offset, unsigned int pread_flags);
 
 void release_firmware(const struct firmware *fw);
 #else
@@ -89,7 +92,8 @@ static inline int request_firmware_direct(const struct firmware **fw,
 }
 
 static inline int request_firmware_into_buf(const struct firmware **firmware_p,
-	const char *name, struct device *device, void *buf, size_t size)
+	const char *name, struct device *device, void *buf, size_t size,
+	size_t offset, unsigned int pread_flags);
 {
 	return -EINVAL;
 }
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH 3/3] soc: qcom: mdt_loader: add offset to request_firmware_into_buf
  2019-05-23  2:51 [PATCH 0/3] fs: add partial file read support Scott Branden
  2019-05-23  2:51 ` [PATCH 1/3] fs: introduce kernel_pread_file* support Scott Branden
  2019-05-23  2:51 ` [PATCH 2/3] firmware: add offset to request_firmware_into_buf Scott Branden
@ 2019-05-23  2:51 ` Scott Branden
  2019-05-23  5:52   ` Greg Kroah-Hartman
  2 siblings, 1 reply; 20+ messages in thread
From: Scott Branden @ 2019-05-23  2:51 UTC (permalink / raw)
  To: Luis Chamberlain, Greg Kroah-Hartman, Andy Gross, David Brown,
	Alexander Viro
  Cc: Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Scott Branden

Adjust request_firmware_into_buf API to allow for portions
of firmware file to be read into a buffer.  mdt_loader still
retricts request fo whole file read into buffer.

Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
 drivers/soc/qcom/mdt_loader.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
index 1c488024c698..ad20d159699c 100644
--- a/drivers/soc/qcom/mdt_loader.c
+++ b/drivers/soc/qcom/mdt_loader.c
@@ -172,8 +172,11 @@ static int __qcom_mdt_load(struct device *dev, const struct firmware *fw,
 
 		if (phdr->p_filesz) {
 			sprintf(fw_name + fw_name_len - 3, "b%02d", i);
-			ret = request_firmware_into_buf(&seg_fw, fw_name, dev,
-							ptr, phdr->p_filesz);
+			ret = request_firmware_into_buf
+						(&seg_fw, fw_name, dev,
+						 ptr, phdr->p_filesz,
+						 0,
+						 KERNEL_PREAD_FLAG_WHOLE);
 			if (ret) {
 				dev_err(dev, "failed to load %s\n", fw_name);
 				break;
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/3] soc: qcom: mdt_loader: add offset to request_firmware_into_buf
  2019-05-23  2:51 ` [PATCH 3/3] soc: qcom: mdt_loader: " Scott Branden
@ 2019-05-23  5:52   ` Greg Kroah-Hartman
  2019-05-23 16:41     ` Scott Branden
  0 siblings, 1 reply; 20+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-23  5:52 UTC (permalink / raw)
  To: Scott Branden
  Cc: Luis Chamberlain, Andy Gross, David Brown, Alexander Viro,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson

On Wed, May 22, 2019 at 07:51:13PM -0700, Scott Branden wrote:
> Adjust request_firmware_into_buf API to allow for portions
> of firmware file to be read into a buffer.  mdt_loader still
> retricts request fo whole file read into buffer.
> 
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> ---
>  drivers/soc/qcom/mdt_loader.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
> index 1c488024c698..ad20d159699c 100644
> --- a/drivers/soc/qcom/mdt_loader.c
> +++ b/drivers/soc/qcom/mdt_loader.c
> @@ -172,8 +172,11 @@ static int __qcom_mdt_load(struct device *dev, const struct firmware *fw,
>  
>  		if (phdr->p_filesz) {
>  			sprintf(fw_name + fw_name_len - 3, "b%02d", i);
> -			ret = request_firmware_into_buf(&seg_fw, fw_name, dev,
> -							ptr, phdr->p_filesz);
> +			ret = request_firmware_into_buf
> +						(&seg_fw, fw_name, dev,
> +						 ptr, phdr->p_filesz,
> +						 0,
> +						 KERNEL_PREAD_FLAG_WHOLE);

So, all that work in the first 2 patches for no real change at all?  Why
are these changes even needed?

And didn't you break this driver in patch 2/3?  You can't fix it up
later here, you need to also resolve that in the 2nd patch.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/3] firmware: add offset to request_firmware_into_buf
  2019-05-23  2:51 ` [PATCH 2/3] firmware: add offset to request_firmware_into_buf Scott Branden
@ 2019-05-23  5:52   ` Greg Kroah-Hartman
  2019-05-23 16:36     ` Scott Branden
  0 siblings, 1 reply; 20+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-23  5:52 UTC (permalink / raw)
  To: Scott Branden
  Cc: Luis Chamberlain, Andy Gross, David Brown, Alexander Viro,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson

On Wed, May 22, 2019 at 07:51:12PM -0700, Scott Branden wrote:
> Add offset to request_firmware_into_buf to allow for portions
> of firmware file to be read into a buffer.  Necessary where firmware
> needs to be loaded in portions from file in memory constrained systems.
> 
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> ---
>  drivers/base/firmware_loader/firmware.h |  5 +++
>  drivers/base/firmware_loader/main.c     | 49 +++++++++++++++++--------
>  include/linux/firmware.h                |  8 +++-
>  3 files changed, 45 insertions(+), 17 deletions(-)

No new firmware test for this new option?  How do we know it even works?
:)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/3] firmware: add offset to request_firmware_into_buf
  2019-05-23  5:52   ` Greg Kroah-Hartman
@ 2019-05-23 16:36     ` Scott Branden
  2019-05-23 16:54       ` Greg Kroah-Hartman
  0 siblings, 1 reply; 20+ messages in thread
From: Scott Branden @ 2019-05-23 16:36 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Luis Chamberlain, Andy Gross, David Brown, Alexander Viro,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson

Hi Greg,

On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
> On Wed, May 22, 2019 at 07:51:12PM -0700, Scott Branden wrote:
>> Add offset to request_firmware_into_buf to allow for portions
>> of firmware file to be read into a buffer.  Necessary where firmware
>> needs to be loaded in portions from file in memory constrained systems.
>>
>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>> ---
>>   drivers/base/firmware_loader/firmware.h |  5 +++
>>   drivers/base/firmware_loader/main.c     | 49 +++++++++++++++++--------
>>   include/linux/firmware.h                |  8 +++-
>>   3 files changed, 45 insertions(+), 17 deletions(-)
> No new firmware test for this new option?  How do we know it even works?

I was unaware there are existing firmware tests.  Please let me know 
where these tests exists and I can add a test for this new option.

We have tested this with a new driver in development which requires the 
firmware file to be read in portions into memory.  I can add my 
tested-by and others to the commit message if desired.

> :)
>
> thanks,
>
> greg k-h

Regards,

Scott


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/3] soc: qcom: mdt_loader: add offset to request_firmware_into_buf
  2019-05-23  5:52   ` Greg Kroah-Hartman
@ 2019-05-23 16:41     ` Scott Branden
  2019-05-23 16:56       ` Greg Kroah-Hartman
  0 siblings, 1 reply; 20+ messages in thread
From: Scott Branden @ 2019-05-23 16:41 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Luis Chamberlain, Andy Gross, David Brown, Alexander Viro,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson

Hi Greg,

On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
> On Wed, May 22, 2019 at 07:51:13PM -0700, Scott Branden wrote:
>> Adjust request_firmware_into_buf API to allow for portions
>> of firmware file to be read into a buffer.  mdt_loader still
>> retricts request fo whole file read into buffer.
>>
>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>> ---
>>   drivers/soc/qcom/mdt_loader.c | 7 +++++--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
>> index 1c488024c698..ad20d159699c 100644
>> --- a/drivers/soc/qcom/mdt_loader.c
>> +++ b/drivers/soc/qcom/mdt_loader.c
>> @@ -172,8 +172,11 @@ static int __qcom_mdt_load(struct device *dev, const struct firmware *fw,
>>   
>>   		if (phdr->p_filesz) {
>>   			sprintf(fw_name + fw_name_len - 3, "b%02d", i);
>> -			ret = request_firmware_into_buf(&seg_fw, fw_name, dev,
>> -							ptr, phdr->p_filesz);
>> +			ret = request_firmware_into_buf
>> +						(&seg_fw, fw_name, dev,
>> +						 ptr, phdr->p_filesz,
>> +						 0,
>> +						 KERNEL_PREAD_FLAG_WHOLE);
> So, all that work in the first 2 patches for no real change at all?  Why
> are these changes even needed?

The first two patches allow partial read of files into memory.

Existing kernel drivers haven't need such functionality so, yes, there 
should be no real change

with first two patches other than adding such partial file read support.

We have a new driver in development which needs partial read of files 
supported in the kernel.

>
> And didn't you break this driver in patch 2/3?  You can't fix it up
> later here, you need to also resolve that in the 2nd patch.

I thought the driver changes needs to be in a different patch. If 
required I can squash this

driver change in with the request_firmware_into_buf change.

But the 2nd patch won't work without the 1st patch either.

So that would mean you now want all 3 patches for different subsystems 
squashed together?

Please let me know how you would like the patch series submitted.

>
> thanks,
>
> greg k-h

Regards,

  Scott


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/3] firmware: add offset to request_firmware_into_buf
  2019-05-23 16:36     ` Scott Branden
@ 2019-05-23 16:54       ` Greg Kroah-Hartman
  2019-05-24  5:01         ` Scott Branden
  0 siblings, 1 reply; 20+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-23 16:54 UTC (permalink / raw)
  To: Scott Branden
  Cc: Luis Chamberlain, Andy Gross, David Brown, Alexander Viro,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson

On Thu, May 23, 2019 at 09:36:02AM -0700, Scott Branden wrote:
> Hi Greg,
> 
> On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
> > On Wed, May 22, 2019 at 07:51:12PM -0700, Scott Branden wrote:
> > > Add offset to request_firmware_into_buf to allow for portions
> > > of firmware file to be read into a buffer.  Necessary where firmware
> > > needs to be loaded in portions from file in memory constrained systems.
> > > 
> > > Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> > > ---
> > >   drivers/base/firmware_loader/firmware.h |  5 +++
> > >   drivers/base/firmware_loader/main.c     | 49 +++++++++++++++++--------
> > >   include/linux/firmware.h                |  8 +++-
> > >   3 files changed, 45 insertions(+), 17 deletions(-)
> > No new firmware test for this new option?  How do we know it even works?
> 
> I was unaware there are existing firmware tests.  Please let me know where
> these tests exists and I can add a test for this new option.

tools/testing/selftests/firmware/

> We have tested this with a new driver in development which requires the
> firmware file to be read in portions into memory.  I can add my tested-by
> and others to the commit message if desired.

I can't take new apis without an in-kernel user, you all know this...

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/3] soc: qcom: mdt_loader: add offset to request_firmware_into_buf
  2019-05-23 16:41     ` Scott Branden
@ 2019-05-23 16:56       ` Greg Kroah-Hartman
  2019-05-27  5:36         ` Bjorn Andersson
  2019-08-22 19:33         ` Scott Branden
  0 siblings, 2 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-23 16:56 UTC (permalink / raw)
  To: Scott Branden
  Cc: Luis Chamberlain, Andy Gross, David Brown, Alexander Viro,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson

On Thu, May 23, 2019 at 09:41:49AM -0700, Scott Branden wrote:
> Hi Greg,
> 
> On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
> > On Wed, May 22, 2019 at 07:51:13PM -0700, Scott Branden wrote:
> > > Adjust request_firmware_into_buf API to allow for portions
> > > of firmware file to be read into a buffer.  mdt_loader still
> > > retricts request fo whole file read into buffer.
> > > 
> > > Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> > > ---
> > >   drivers/soc/qcom/mdt_loader.c | 7 +++++--
> > >   1 file changed, 5 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
> > > index 1c488024c698..ad20d159699c 100644
> > > --- a/drivers/soc/qcom/mdt_loader.c
> > > +++ b/drivers/soc/qcom/mdt_loader.c
> > > @@ -172,8 +172,11 @@ static int __qcom_mdt_load(struct device *dev, const struct firmware *fw,
> > >   		if (phdr->p_filesz) {
> > >   			sprintf(fw_name + fw_name_len - 3, "b%02d", i);
> > > -			ret = request_firmware_into_buf(&seg_fw, fw_name, dev,
> > > -							ptr, phdr->p_filesz);
> > > +			ret = request_firmware_into_buf
> > > +						(&seg_fw, fw_name, dev,
> > > +						 ptr, phdr->p_filesz,
> > > +						 0,
> > > +						 KERNEL_PREAD_FLAG_WHOLE);
> > So, all that work in the first 2 patches for no real change at all?  Why
> > are these changes even needed?
> 
> The first two patches allow partial read of files into memory.
> 
> Existing kernel drivers haven't need such functionality so, yes, there
> should be no real change
> 
> with first two patches other than adding such partial file read support.
> 
> We have a new driver in development which needs partial read of files
> supported in the kernel.

As I said before, I can not take new apis without any in-kernel user.
So let's wait for your new code that thinks it needs this, and then we
will be glad to evaluate all of this at that point in time.

To do so otherwise is to have loads of unused "features" aquiring cruft
in the kernel source, and you do not want that.

> > And didn't you break this driver in patch 2/3?  You can't fix it up
> > later here, you need to also resolve that in the 2nd patch.
> 
> I thought the driver changes needs to be in a different patch. If required I
> can squash this

You can NEVER break the build with any individual kernel patch, that
should be well known by now as we have been doing this for over a
decade.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/3] firmware: add offset to request_firmware_into_buf
  2019-05-23 16:54       ` Greg Kroah-Hartman
@ 2019-05-24  5:01         ` Scott Branden
  2019-05-24  5:22           ` Greg Kroah-Hartman
  0 siblings, 1 reply; 20+ messages in thread
From: Scott Branden @ 2019-05-24  5:01 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Luis Chamberlain, David Brown, Alexander Viro,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson


On 2019-05-23 9:54 a.m., Greg Kroah-Hartman wrote:
> On Thu, May 23, 2019 at 09:36:02AM -0700, Scott Branden wrote:
>> Hi Greg,
>>
>> On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
>>> On Wed, May 22, 2019 at 07:51:12PM -0700, Scott Branden wrote:
>>>> Add offset to request_firmware_into_buf to allow for portions
>>>> of firmware file to be read into a buffer.  Necessary where firmware
>>>> needs to be loaded in portions from file in memory constrained systems.
>>>>
>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>> ---
>>>>    drivers/base/firmware_loader/firmware.h |  5 +++
>>>>    drivers/base/firmware_loader/main.c     | 49 +++++++++++++++++--------
>>>>    include/linux/firmware.h                |  8 +++-
>>>>    3 files changed, 45 insertions(+), 17 deletions(-)
>>> No new firmware test for this new option?  How do we know it even works?
>> I was unaware there are existing firmware tests.  Please let me know where
>> these tests exists and I can add a test for this new option.
> tools/testing/selftests/firmware/

Unfortunately, there doesn't seem to be a test for the existing 
request_firmware_into_buf api.

Looks like it will be more work that I thought enhancing a test that 
doesn't exist.


>
>> We have tested this with a new driver in development which requires the
>> firmware file to be read in portions into memory.  I can add my tested-by
>> and others to the commit message if desired.
> I can't take new apis without an in-kernel user, you all know this...

OK, It will have to wait then as I was hoping to get this in before my 
leave.

But adding a selftest and upstreaming the necessary driver

won't be possible for a few months now.

>
> thanks,
>
> greg k-h

Thanks for explaining the requirements.


Scott


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/3] firmware: add offset to request_firmware_into_buf
  2019-05-24  5:01         ` Scott Branden
@ 2019-05-24  5:22           ` Greg Kroah-Hartman
  2019-08-01  0:18             ` Scott Branden
  0 siblings, 1 reply; 20+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-24  5:22 UTC (permalink / raw)
  To: Scott Branden
  Cc: Luis Chamberlain, David Brown, Alexander Viro,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson

On Thu, May 23, 2019 at 10:01:38PM -0700, Scott Branden wrote:
> 
> On 2019-05-23 9:54 a.m., Greg Kroah-Hartman wrote:
> > On Thu, May 23, 2019 at 09:36:02AM -0700, Scott Branden wrote:
> > > Hi Greg,
> > > 
> > > On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
> > > > On Wed, May 22, 2019 at 07:51:12PM -0700, Scott Branden wrote:
> > > > > Add offset to request_firmware_into_buf to allow for portions
> > > > > of firmware file to be read into a buffer.  Necessary where firmware
> > > > > needs to be loaded in portions from file in memory constrained systems.
> > > > > 
> > > > > Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> > > > > ---
> > > > >    drivers/base/firmware_loader/firmware.h |  5 +++
> > > > >    drivers/base/firmware_loader/main.c     | 49 +++++++++++++++++--------
> > > > >    include/linux/firmware.h                |  8 +++-
> > > > >    3 files changed, 45 insertions(+), 17 deletions(-)
> > > > No new firmware test for this new option?  How do we know it even works?
> > > I was unaware there are existing firmware tests.  Please let me know where
> > > these tests exists and I can add a test for this new option.
> > tools/testing/selftests/firmware/
> 
> Unfortunately, there doesn't seem to be a test for the existing
> request_firmware_into_buf api.

Are you sure?  The test is for userspace functionality, there isn't
kernel unit tests here.  You need to verify that you didn't break
existing functionality as well as verify that your new functionality
works.

> > > We have tested this with a new driver in development which requires the
> > > firmware file to be read in portions into memory.  I can add my tested-by
> > > and others to the commit message if desired.
> > I can't take new apis without an in-kernel user, you all know this...
> 
> OK, It will have to wait then as I was hoping to get this in before my
> leave.

Throwing new code over the wall and running away is a sure way to ensure
that your code will be ignored :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/3] soc: qcom: mdt_loader: add offset to request_firmware_into_buf
  2019-05-23 16:56       ` Greg Kroah-Hartman
@ 2019-05-27  5:36         ` Bjorn Andersson
  2019-07-30 23:02           ` Scott Branden
  2019-08-22 19:33         ` Scott Branden
  1 sibling, 1 reply; 20+ messages in thread
From: Bjorn Andersson @ 2019-05-27  5:36 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Scott Branden, Luis Chamberlain, Andy Gross, David Brown,
	Alexander Viro, Rafael J . Wysocki, linux-kernel, linux-arm-msm,
	linux-fsdevel, BCM Kernel Feedback, Olof Johansson

On Thu 23 May 09:56 PDT 2019, Greg Kroah-Hartman wrote:

> On Thu, May 23, 2019 at 09:41:49AM -0700, Scott Branden wrote:
> > Hi Greg,
> > 
> > On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
> > > On Wed, May 22, 2019 at 07:51:13PM -0700, Scott Branden wrote:
> > > > Adjust request_firmware_into_buf API to allow for portions
> > > > of firmware file to be read into a buffer.  mdt_loader still
> > > > retricts request fo whole file read into buffer.
> > > > 
> > > > Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> > > > ---
> > > >   drivers/soc/qcom/mdt_loader.c | 7 +++++--
> > > >   1 file changed, 5 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
> > > > index 1c488024c698..ad20d159699c 100644
> > > > --- a/drivers/soc/qcom/mdt_loader.c
> > > > +++ b/drivers/soc/qcom/mdt_loader.c
> > > > @@ -172,8 +172,11 @@ static int __qcom_mdt_load(struct device *dev, const struct firmware *fw,
> > > >   		if (phdr->p_filesz) {
> > > >   			sprintf(fw_name + fw_name_len - 3, "b%02d", i);
> > > > -			ret = request_firmware_into_buf(&seg_fw, fw_name, dev,
> > > > -							ptr, phdr->p_filesz);
> > > > +			ret = request_firmware_into_buf
> > > > +						(&seg_fw, fw_name, dev,
> > > > +						 ptr, phdr->p_filesz,
> > > > +						 0,
> > > > +						 KERNEL_PREAD_FLAG_WHOLE);
> > > So, all that work in the first 2 patches for no real change at all?  Why
> > > are these changes even needed?
> > 
> > The first two patches allow partial read of files into memory.
> > 
> > Existing kernel drivers haven't need such functionality so, yes, there
> > should be no real change
> > 
> > with first two patches other than adding such partial file read support.
> > 
> > We have a new driver in development which needs partial read of files
> > supported in the kernel.
> 
> As I said before, I can not take new apis without any in-kernel user.
> So let's wait for your new code that thinks it needs this, and then we
> will be glad to evaluate all of this at that point in time.
> 

The .mdt files are ELF files split to avoid having to allocate large
(5-60MB) chunks of temporary firmware buffers while installing the
segments.

But for multiple reasons it would be nice to be able to load the
non-split ELF files and the proposed interface would allow this.

So I definitely like the gist of the series.

> To do so otherwise is to have loads of unused "features" aquiring cruft
> in the kernel source, and you do not want that.
> 

Agreed.

I'll take the opportunity and see if I can implement this (support for
non-split Qualcomm firmware) based on the patches in this series.

Regards,
Bjorn

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/3] soc: qcom: mdt_loader: add offset to request_firmware_into_buf
  2019-05-27  5:36         ` Bjorn Andersson
@ 2019-07-30 23:02           ` Scott Branden
  0 siblings, 0 replies; 20+ messages in thread
From: Scott Branden @ 2019-07-30 23:02 UTC (permalink / raw)
  To: Bjorn Andersson, Greg Kroah-Hartman
  Cc: Luis Chamberlain, Andy Gross, David Brown, Alexander Viro,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson

Hi Bjorn,

On 2019-05-26 10:36 p.m., Bjorn Andersson wrote:
> On Thu 23 May 09:56 PDT 2019, Greg Kroah-Hartman wrote:
>
>> On Thu, May 23, 2019 at 09:41:49AM -0700, Scott Branden wrote:
>>> Hi Greg,
>>>
>>> On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
>>>> On Wed, May 22, 2019 at 07:51:13PM -0700, Scott Branden wrote:
>>>>> Adjust request_firmware_into_buf API to allow for portions
>>>>> of firmware file to be read into a buffer.  mdt_loader still
>>>>> retricts request fo whole file read into buffer.
>>>>>
>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>> ---
>>>>>    drivers/soc/qcom/mdt_loader.c | 7 +++++--
>>>>>    1 file changed, 5 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
>>>>> index 1c488024c698..ad20d159699c 100644
>>>>> --- a/drivers/soc/qcom/mdt_loader.c
>>>>> +++ b/drivers/soc/qcom/mdt_loader.c
>>>>> @@ -172,8 +172,11 @@ static int __qcom_mdt_load(struct device *dev, const struct firmware *fw,
>>>>>    		if (phdr->p_filesz) {
>>>>>    			sprintf(fw_name + fw_name_len - 3, "b%02d", i);
>>>>> -			ret = request_firmware_into_buf(&seg_fw, fw_name, dev,
>>>>> -							ptr, phdr->p_filesz);
>>>>> +			ret = request_firmware_into_buf
>>>>> +						(&seg_fw, fw_name, dev,
>>>>> +						 ptr, phdr->p_filesz,
>>>>> +						 0,
>>>>> +						 KERNEL_PREAD_FLAG_WHOLE);
>>>> So, all that work in the first 2 patches for no real change at all?  Why
>>>> are these changes even needed?
>>> The first two patches allow partial read of files into memory.
>>>
>>> Existing kernel drivers haven't need such functionality so, yes, there
>>> should be no real change
>>>
>>> with first two patches other than adding such partial file read support.
>>>
>>> We have a new driver in development which needs partial read of files
>>> supported in the kernel.
>> As I said before, I can not take new apis without any in-kernel user.
>> So let's wait for your new code that thinks it needs this, and then we
>> will be glad to evaluate all of this at that point in time.
>>
> The .mdt files are ELF files split to avoid having to allocate large
> (5-60MB) chunks of temporary firmware buffers while installing the
> segments.
>
> But for multiple reasons it would be nice to be able to load the
> non-split ELF files and the proposed interface would allow this.
>
> So I definitely like the gist of the series.
>
>> To do so otherwise is to have loads of unused "features" aquiring cruft
>> in the kernel source, and you do not want that.
>>
> Agreed.
>
> I'll take the opportunity and see if I can implement this (support for
> non-split Qualcomm firmware) based on the patches in this series.

I'm back from my leave now.

Have you managed to utilize my partial firmware read in your driver yet?

>
> Regards,
> Bjorn

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/3] firmware: add offset to request_firmware_into_buf
  2019-05-24  5:22           ` Greg Kroah-Hartman
@ 2019-08-01  0:18             ` Scott Branden
  2019-08-01  6:18               ` Greg Kroah-Hartman
  0 siblings, 1 reply; 20+ messages in thread
From: Scott Branden @ 2019-08-01  0:18 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Luis Chamberlain, David Brown, Alexander Viro,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson

Hi Greg,

I am now back from leave to continue this patch.  Comment below.

On 2019-05-23 10:22 p.m., Greg Kroah-Hartman wrote:
> On Thu, May 23, 2019 at 10:01:38PM -0700, Scott Branden wrote:
>> On 2019-05-23 9:54 a.m., Greg Kroah-Hartman wrote:
>>> On Thu, May 23, 2019 at 09:36:02AM -0700, Scott Branden wrote:
>>>> Hi Greg,
>>>>
>>>> On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
>>>>> On Wed, May 22, 2019 at 07:51:12PM -0700, Scott Branden wrote:
>>>>>> Add offset to request_firmware_into_buf to allow for portions
>>>>>> of firmware file to be read into a buffer.  Necessary where firmware
>>>>>> needs to be loaded in portions from file in memory constrained systems.
>>>>>>
>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>>> ---
>>>>>>     drivers/base/firmware_loader/firmware.h |  5 +++
>>>>>>     drivers/base/firmware_loader/main.c     | 49 +++++++++++++++++--------
>>>>>>     include/linux/firmware.h                |  8 +++-
>>>>>>     3 files changed, 45 insertions(+), 17 deletions(-)
>>>>> No new firmware test for this new option?  How do we know it even works?
>>>> I was unaware there are existing firmware tests.  Please let me know where
>>>> these tests exists and I can add a test for this new option.
>>> tools/testing/selftests/firmware/
>> Unfortunately, there doesn't seem to be a test for the existing
>> request_firmware_into_buf api.
> Are you sure?  The test is for userspace functionality, there isn't
> kernel unit tests here.  You need to verify that you didn't break
> existing functionality as well as verify that your new functionality
> works.

I managed to figure out how to build and run 
tools/testing/selftest/firmware/fw_run_tests.sh

and my changes don't break existing functionality.

But, I find no use of request_firmware_into_buf in lib/test_firmware.c 
(triggered by fw_run_tests.sh).

Is there another test for request_firmware_into_buf?

>>>> We have tested this with a new driver in development which requires the
>>>> firmware file to be read in portions into memory.  I can add my tested-by
>>>> and others to the commit message if desired.
>>> I can't take new apis without an in-kernel user, you all know this...
>> OK, It will have to wait then as I was hoping to get this in before my
>> leave.
> Throwing new code over the wall and running away is a sure way to ensure
> that your code will be ignored :)
>
> thanks,
>
> greg k-h

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/3] firmware: add offset to request_firmware_into_buf
  2019-08-01  0:18             ` Scott Branden
@ 2019-08-01  6:18               ` Greg Kroah-Hartman
  2019-08-01 17:42                 ` Luis Chamberlain
  0 siblings, 1 reply; 20+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-01  6:18 UTC (permalink / raw)
  To: Scott Branden
  Cc: Luis Chamberlain, David Brown, Alexander Viro,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson

On Wed, Jul 31, 2019 at 05:18:32PM -0700, Scott Branden wrote:
> Hi Greg,
> 
> I am now back from leave to continue this patch.  Comment below.
> 
> On 2019-05-23 10:22 p.m., Greg Kroah-Hartman wrote:
> > On Thu, May 23, 2019 at 10:01:38PM -0700, Scott Branden wrote:
> > > On 2019-05-23 9:54 a.m., Greg Kroah-Hartman wrote:
> > > > On Thu, May 23, 2019 at 09:36:02AM -0700, Scott Branden wrote:
> > > > > Hi Greg,
> > > > > 
> > > > > On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
> > > > > > On Wed, May 22, 2019 at 07:51:12PM -0700, Scott Branden wrote:
> > > > > > > Add offset to request_firmware_into_buf to allow for portions
> > > > > > > of firmware file to be read into a buffer.  Necessary where firmware
> > > > > > > needs to be loaded in portions from file in memory constrained systems.
> > > > > > > 
> > > > > > > Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> > > > > > > ---
> > > > > > >     drivers/base/firmware_loader/firmware.h |  5 +++
> > > > > > >     drivers/base/firmware_loader/main.c     | 49 +++++++++++++++++--------
> > > > > > >     include/linux/firmware.h                |  8 +++-
> > > > > > >     3 files changed, 45 insertions(+), 17 deletions(-)
> > > > > > No new firmware test for this new option?  How do we know it even works?
> > > > > I was unaware there are existing firmware tests.  Please let me know where
> > > > > these tests exists and I can add a test for this new option.
> > > > tools/testing/selftests/firmware/
> > > Unfortunately, there doesn't seem to be a test for the existing
> > > request_firmware_into_buf api.
> > Are you sure?  The test is for userspace functionality, there isn't
> > kernel unit tests here.  You need to verify that you didn't break
> > existing functionality as well as verify that your new functionality
> > works.
> 
> I managed to figure out how to build and run
> tools/testing/selftest/firmware/fw_run_tests.sh
> 
> and my changes don't break existing functionality.
> 
> But, I find no use of request_firmware_into_buf in lib/test_firmware.c
> (triggered by fw_run_tests.sh).
> 
> Is there another test for request_firmware_into_buf?

I have no idea, sorry.

greg k-h

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/3] firmware: add offset to request_firmware_into_buf
  2019-08-01  6:18               ` Greg Kroah-Hartman
@ 2019-08-01 17:42                 ` Luis Chamberlain
  2019-08-01 18:15                   ` Scott Branden
  0 siblings, 1 reply; 20+ messages in thread
From: Luis Chamberlain @ 2019-08-01 17:42 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Scott Branden, David Brown, Alexander Viro, Rafael J . Wysocki,
	linux-kernel, linux-arm-msm, linux-fsdevel, BCM Kernel Feedback,
	Olof Johansson

On Thu, Aug 01, 2019 at 08:18:01AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 31, 2019 at 05:18:32PM -0700, Scott Branden wrote:
> > Hi Greg,
> > 
> > I am now back from leave to continue this patch.  Comment below.
> > 
> > On 2019-05-23 10:22 p.m., Greg Kroah-Hartman wrote:
> > > On Thu, May 23, 2019 at 10:01:38PM -0700, Scott Branden wrote:
> > > > On 2019-05-23 9:54 a.m., Greg Kroah-Hartman wrote:
> > > > > On Thu, May 23, 2019 at 09:36:02AM -0700, Scott Branden wrote:
> > > > > > Hi Greg,
> > > > > > 
> > > > > > On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
> > > > > > > On Wed, May 22, 2019 at 07:51:12PM -0700, Scott Branden wrote:
> > > > > > > > Add offset to request_firmware_into_buf to allow for portions
> > > > > > > > of firmware file to be read into a buffer.  Necessary where firmware
> > > > > > > > needs to be loaded in portions from file in memory constrained systems.
> > > > > > > > 
> > > > > > > > Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> > > > > > > > ---
> > > > > > > >     drivers/base/firmware_loader/firmware.h |  5 +++
> > > > > > > >     drivers/base/firmware_loader/main.c     | 49 +++++++++++++++++--------
> > > > > > > >     include/linux/firmware.h                |  8 +++-
> > > > > > > >     3 files changed, 45 insertions(+), 17 deletions(-)
> > > > > > > No new firmware test for this new option?  How do we know it even works?
> > > > > > I was unaware there are existing firmware tests.  Please let me know where
> > > > > > these tests exists and I can add a test for this new option.
> > > > > tools/testing/selftests/firmware/
> > > > Unfortunately, there doesn't seem to be a test for the existing
> > > > request_firmware_into_buf api.
> > > Are you sure?  The test is for userspace functionality, there isn't
> > > kernel unit tests here.  You need to verify that you didn't break
> > > existing functionality as well as verify that your new functionality
> > > works.
> > 
> > I managed to figure out how to build and run
> > tools/testing/selftest/firmware/fw_run_tests.sh
> > 
> > and my changes don't break existing functionality.

I'm soon going to release something that is going to let you do this 
faster and easier, let me know if you had troubles in trying to figure
out how to not regress the kernel using this.

> > But, I find no use of request_firmware_into_buf in lib/test_firmware.c
> > (triggered by fw_run_tests.sh).
> > 
> > Is there another test for request_firmware_into_buf?
> 
> I have no idea, sorry.

The folks who implemented request_firmware_into_buf() didn't add a
respective test, because, well, this API went upstream IMO without much
ACKs / review, and even no damn users. Now we have a user so we're stuck
with it.

So new testing calls for it would be appreciated. If you have questions
I am happy to help.

  Luis

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/3] firmware: add offset to request_firmware_into_buf
  2019-08-01 17:42                 ` Luis Chamberlain
@ 2019-08-01 18:15                   ` Scott Branden
  2019-08-19 22:22                     ` Luis Chamberlain
  0 siblings, 1 reply; 20+ messages in thread
From: Scott Branden @ 2019-08-01 18:15 UTC (permalink / raw)
  To: Luis Chamberlain, Greg Kroah-Hartman
  Cc: David Brown, Alexander Viro, Rafael J . Wysocki, linux-kernel,
	linux-arm-msm, linux-fsdevel, BCM Kernel Feedback,
	Olof Johansson

Hi Luis,

On 2019-08-01 10:42 a.m., Luis Chamberlain wrote:
> On Thu, Aug 01, 2019 at 08:18:01AM +0200, Greg Kroah-Hartman wrote:
>> On Wed, Jul 31, 2019 at 05:18:32PM -0700, Scott Branden wrote:
>>> Hi Greg,
>>>
>>> I am now back from leave to continue this patch.  Comment below.
>>>
>>> On 2019-05-23 10:22 p.m., Greg Kroah-Hartman wrote:
>>>> On Thu, May 23, 2019 at 10:01:38PM -0700, Scott Branden wrote:
>>>>> On 2019-05-23 9:54 a.m., Greg Kroah-Hartman wrote:
>>>>>> On Thu, May 23, 2019 at 09:36:02AM -0700, Scott Branden wrote:
>>>>>>> Hi Greg,
>>>>>>>
>>>>>>> On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
>>>>>>>> On Wed, May 22, 2019 at 07:51:12PM -0700, Scott Branden wrote:
>>>>>>>>> Add offset to request_firmware_into_buf to allow for portions
>>>>>>>>> of firmware file to be read into a buffer.  Necessary where firmware
>>>>>>>>> needs to be loaded in portions from file in memory constrained systems.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>>>>>> ---
>>>>>>>>>      drivers/base/firmware_loader/firmware.h |  5 +++
>>>>>>>>>      drivers/base/firmware_loader/main.c     | 49 +++++++++++++++++--------
>>>>>>>>>      include/linux/firmware.h                |  8 +++-
>>>>>>>>>      3 files changed, 45 insertions(+), 17 deletions(-)
>>>>>>>> No new firmware test for this new option?  How do we know it even works?
>>>>>>> I was unaware there are existing firmware tests.  Please let me know where
>>>>>>> these tests exists and I can add a test for this new option.
>>>>>> tools/testing/selftests/firmware/
>>>>> Unfortunately, there doesn't seem to be a test for the existing
>>>>> request_firmware_into_buf api.
>>>> Are you sure?  The test is for userspace functionality, there isn't
>>>> kernel unit tests here.  You need to verify that you didn't break
>>>> existing functionality as well as verify that your new functionality
>>>> works.
>>> I managed to figure out how to build and run
>>> tools/testing/selftest/firmware/fw_run_tests.sh
>>>
>>> and my changes don't break existing functionality.
> I'm soon going to release something that is going to let you do this
> faster and easier, let me know if you had troubles in trying to figure
> out how to not regress the kernel using this.

Yes, I had troubles in trying to figure it out.  The kernel build should

create an entire initrd with all the necessary components in it for 
testing purposes.

And the firmware test will now take me some time to figure out how it 
all works.

Could you please explain what you are going to release soon?  I don't 
want to waste

my time getting something working if everything is going to change on me 
right away?

>
>>> But, I find no use of request_firmware_into_buf in lib/test_firmware.c
>>> (triggered by fw_run_tests.sh).
>>>
>>> Is there another test for request_firmware_into_buf?
>> I have no idea, sorry.
> The folks who implemented request_firmware_into_buf() didn't add a
> respective test, because, well, this API went upstream IMO without much
> ACKs / review, and even no damn users. Now we have a user so we're stuck
> with it.

The request_firmware_into_buf is a necessity for me as well

(along with the need for a partial request of the file which I'm adding).

>
> So new testing calls for it would be appreciated. If you have questions
> I am happy to help.

If you're an expert on the firmware test and can quickly add a simple 
test of request_firmware_into_buf

it would be appreciated.  If not, I'm going to have to dig further into 
this and send early versions of

a test out which would be great for you to comment on.

>
>    Luis

Thanks,

Scott


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/3] firmware: add offset to request_firmware_into_buf
  2019-08-01 18:15                   ` Scott Branden
@ 2019-08-19 22:22                     ` Luis Chamberlain
  0 siblings, 0 replies; 20+ messages in thread
From: Luis Chamberlain @ 2019-08-19 22:22 UTC (permalink / raw)
  To: Scott Branden
  Cc: Greg Kroah-Hartman, David Brown, Alexander Viro,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson

On Thu, Aug 01, 2019 at 11:15:19AM -0700, Scott Branden wrote:
> Hi Luis,
> 
> On 2019-08-01 10:42 a.m., Luis Chamberlain wrote:
> > On Thu, Aug 01, 2019 at 08:18:01AM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Jul 31, 2019 at 05:18:32PM -0700, Scott Branden wrote:
> > > > Hi Greg,
> > > > 
> > > > I am now back from leave to continue this patch.  Comment below.
> > > > 
> > > > On 2019-05-23 10:22 p.m., Greg Kroah-Hartman wrote:
> > > > > On Thu, May 23, 2019 at 10:01:38PM -0700, Scott Branden wrote:
> > > > > > On 2019-05-23 9:54 a.m., Greg Kroah-Hartman wrote:
> > > > > > > On Thu, May 23, 2019 at 09:36:02AM -0700, Scott Branden wrote:
> > > > > > > > Hi Greg,
> > > > > > > > 
> > > > > > > > On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
> > > > > > > > > On Wed, May 22, 2019 at 07:51:12PM -0700, Scott Branden wrote:
> > > > > > > > > > Add offset to request_firmware_into_buf to allow for portions
> > > > > > > > > > of firmware file to be read into a buffer.  Necessary where firmware
> > > > > > > > > > needs to be loaded in portions from file in memory constrained systems.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> > > > > > > > > > ---
> > > > > > > > > >      drivers/base/firmware_loader/firmware.h |  5 +++
> > > > > > > > > >      drivers/base/firmware_loader/main.c     | 49 +++++++++++++++++--------
> > > > > > > > > >      include/linux/firmware.h                |  8 +++-
> > > > > > > > > >      3 files changed, 45 insertions(+), 17 deletions(-)
> > > > > > > > > No new firmware test for this new option?  How do we know it even works?
> > > > > > > > I was unaware there are existing firmware tests.  Please let me know where
> > > > > > > > these tests exists and I can add a test for this new option.
> > > > > > > tools/testing/selftests/firmware/
> > > > > > Unfortunately, there doesn't seem to be a test for the existing
> > > > > > request_firmware_into_buf api.
> > > > > Are you sure?  The test is for userspace functionality, there isn't
> > > > > kernel unit tests here.  You need to verify that you didn't break
> > > > > existing functionality as well as verify that your new functionality
> > > > > works.
> > > > I managed to figure out how to build and run
> > > > tools/testing/selftest/firmware/fw_run_tests.sh
> > > > 
> > > > and my changes don't break existing functionality.
> > I'm soon going to release something that is going to let you do this
> > faster and easier, let me know if you had troubles in trying to figure
> > out how to not regress the kernel using this.
> 
> Yes, I had troubles in trying to figure it out.  The kernel build should
> 
> create an entire initrd with all the necessary components in it for testing
> purposes.
> 
> And the firmware test will now take me some time to figure out how it all
> works.
> 
> Could you please explain what you are going to release soon?  I don't want
> to waste

Sorry for the delay but I promise that I tried hard to get this out ASAP.

https://github.com/mcgrof/fw-kdevops

This now can be used to more easily let you start an environment to
test the firmware API.

Too late for you I gather, but perhaps others can take advantage.

  Luis

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/3] soc: qcom: mdt_loader: add offset to request_firmware_into_buf
  2019-05-23 16:56       ` Greg Kroah-Hartman
  2019-05-27  5:36         ` Bjorn Andersson
@ 2019-08-22 19:33         ` Scott Branden
  1 sibling, 0 replies; 20+ messages in thread
From: Scott Branden @ 2019-08-22 19:33 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Luis Chamberlain, Andy Gross, David Brown, Alexander Viro,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson

Hi Greg,

On 2019-05-23 9:56 a.m., Greg Kroah-Hartman wrote:
> On Thu, May 23, 2019 at 09:41:49AM -0700, Scott Branden wrote:
>> Hi Greg,
>>
>> On 2019-05-22 10:52 p.m., Greg Kroah-Hartman wrote:
>>> On Wed, May 22, 2019 at 07:51:13PM -0700, Scott Branden wrote:
>>>> Adjust request_firmware_into_buf API to allow for portions
>>>> of firmware file to be read into a buffer.  mdt_loader still
>>>> retricts request fo whole file read into buffer.
>>>>
>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>> ---
>>>>    drivers/soc/qcom/mdt_loader.c | 7 +++++--
>>>>    1 file changed, 5 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
>>>> index 1c488024c698..ad20d159699c 100644
>>>> --- a/drivers/soc/qcom/mdt_loader.c
>>>> +++ b/drivers/soc/qcom/mdt_loader.c
>>>> @@ -172,8 +172,11 @@ static int __qcom_mdt_load(struct device *dev, const struct firmware *fw,
>>>>    		if (phdr->p_filesz) {
>>>>    			sprintf(fw_name + fw_name_len - 3, "b%02d", i);
>>>> -			ret = request_firmware_into_buf(&seg_fw, fw_name, dev,
>>>> -							ptr, phdr->p_filesz);
>>>> +			ret = request_firmware_into_buf
>>>> +						(&seg_fw, fw_name, dev,
>>>> +						 ptr, phdr->p_filesz,
>>>> +						 0,
>>>> +						 KERNEL_PREAD_FLAG_WHOLE);
>>> So, all that work in the first 2 patches for no real change at all?  Why
>>> are these changes even needed?
>> The first two patches allow partial read of files into memory.
>>
>> Existing kernel drivers haven't need such functionality so, yes, there
>> should be no real change
>>
>> with first two patches other than adding such partial file read support.
>>
>> We have a new driver in development which needs partial read of files
>> supported in the kernel.
> As I said before, I can not take new apis without any in-kernel user.
> So let's wait for your new code that thinks it needs this, and then we
> will be glad to evaluate all of this at that point in time.

I have submitted all the necessary patches you requested here.

These include first adding tests for existing API that never had a 
kernel selftest:

https://lkml.org/lkml/2019/8/22/1367

Followed by API enhancement, tests updated, and a new driver requiring 
enhanced API:

https://lkml.org/lkml/2019/8/22/1404

>
> To do so otherwise is to have loads of unused "features" aquiring cruft
> in the kernel source, and you do not want that.
>
> thanks,
>
> greg k-h

Thanks,

Scott


^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2019-08-22 19:33 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-23  2:51 [PATCH 0/3] fs: add partial file read support Scott Branden
2019-05-23  2:51 ` [PATCH 1/3] fs: introduce kernel_pread_file* support Scott Branden
2019-05-23  2:51 ` [PATCH 2/3] firmware: add offset to request_firmware_into_buf Scott Branden
2019-05-23  5:52   ` Greg Kroah-Hartman
2019-05-23 16:36     ` Scott Branden
2019-05-23 16:54       ` Greg Kroah-Hartman
2019-05-24  5:01         ` Scott Branden
2019-05-24  5:22           ` Greg Kroah-Hartman
2019-08-01  0:18             ` Scott Branden
2019-08-01  6:18               ` Greg Kroah-Hartman
2019-08-01 17:42                 ` Luis Chamberlain
2019-08-01 18:15                   ` Scott Branden
2019-08-19 22:22                     ` Luis Chamberlain
2019-05-23  2:51 ` [PATCH 3/3] soc: qcom: mdt_loader: " Scott Branden
2019-05-23  5:52   ` Greg Kroah-Hartman
2019-05-23 16:41     ` Scott Branden
2019-05-23 16:56       ` Greg Kroah-Hartman
2019-05-27  5:36         ` Bjorn Andersson
2019-07-30 23:02           ` Scott Branden
2019-08-22 19:33         ` Scott Branden

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).