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@xxxxxxxxxxxx>
---
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
