diff mbox series

[3/3] soc: qcom: mdt_loader: add offset to request_firmware_into_buf

Message ID 20190523025113.4605-4-scott.branden@broadcom.com (mailing list archive)
State New, archived
Headers show
Series fs: add partial file read support | expand

Commit Message

Scott Branden May 23, 2019, 2:51 a.m. UTC
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(-)

Comments

Greg Kroah-Hartman May 23, 2019, 5:52 a.m. UTC | #1
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
Scott Branden May 23, 2019, 4:41 p.m. UTC | #2
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
Greg Kroah-Hartman May 23, 2019, 4:56 p.m. UTC | #3
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
Bjorn Andersson May 27, 2019, 5:36 a.m. UTC | #4
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
Scott Branden July 30, 2019, 11:02 p.m. UTC | #5
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
Scott Branden Aug. 22, 2019, 7:33 p.m. UTC | #6
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
diff mbox series

Patch

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;