Messages in this thread | | | Subject | Re: [PATCH 3/3] soc: qcom: mdt_loader: add offset to request_firmware_into_buf | From | Scott Branden <> | Date | Thu, 22 Aug 2019 12:33:08 -0700 |
| |
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
| |