linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Scott Branden <scott.branden@broadcom.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	Andy Gross <andy.gross@linaro.org>,
	David Brown <david.brown@linaro.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>,
	Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH 3/3] soc: qcom: mdt_loader: add offset to request_firmware_into_buf
Date: Tue, 30 Jul 2019 16:02:40 -0700	[thread overview]
Message-ID: <4aec9d4e-fd6c-afba-d051-6ab22bdfa17f@broadcom.com> (raw)
In-Reply-To: <20190527053607.GV31438@minitux>

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

  reply	other threads:[~2019-07-30 23:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2019-08-22 19:33         ` Scott Branden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4aec9d4e-fd6c-afba-d051-6ab22bdfa17f@broadcom.com \
    --to=scott.branden@broadcom.com \
    --cc=andy.gross@linaro.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=david.brown@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=olof@lixom.net \
    --cc=rafael@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).