mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Price <steven.price@arm.com>
To: Javier Martinez Canillas <javierm@redhat.com>,
	Andy Yan <andyshrk@163.com>,
	boris.brezillon@collabora.com
Cc: daniel@ffwll.ch, airlied@gmail.com, liviu.dudau@arm.com,
	maarten.lankhorst@linux.intel.com, tzimmermann@suse.de,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Andy Yan <andy.yan@rock-chips.com>
Subject: Re: [PATCH] drm/panthor: Add defer probe for firmware load
Date: Thu, 25 Apr 2024 15:28:56 +0100	[thread overview]
Message-ID: <501d18c9-3116-4cd1-8091-b9f552e9fb5a@arm.com> (raw)
In-Reply-To: <87frv9zthu.fsf@minerva.mail-host-address-is-not-set>

Hi Javier,

On 25/04/2024 10:22, Javier Martinez Canillas wrote:
> Steven Price <steven.price@arm.com> writes:
> 
> Hello Steven,
> 
>> On 13/04/2024 12:49, Andy Yan wrote:
>>> From: Andy Yan <andy.yan@rock-chips.com>
>>>
>>> The firmware in the rootfs will not be accessible until we
>>> are in the SYSTEM_RUNNING state, so return EPROBE_DEFER until
>>> that point.
>>> This let the driver can load firmware when it is builtin.
>>
>> The usual solution is that the firmware should be placed in the
>> initrd/initramfs if the module is included there (or built-in). The same
>> issue was brought up regarding the powervr driver:
>>
>> https://lore.kernel.org/dri-devel/20240109120604.603700-1-javierm@redhat.com/T/
>>
>> I'm not sure if that ever actually reached a conclusion though. The
>> question was deferred to Greg KH but I didn't see Greg actually getting
>> involved in the thread.
>>
> 
> Correct, there was not conclusion reached in that thread.

So I think we need a conclusion before we start applying point fixes to
individual drivers.

>>> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
>>> ---
>>>
>>>  drivers/gpu/drm/panthor/panthor_fw.c | 11 ++++++++++-
>>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/panthor/panthor_fw.c b/drivers/gpu/drm/panthor/panthor_fw.c
>>> index 33c87a59834e..25e375f8333c 100644
>>> --- a/drivers/gpu/drm/panthor/panthor_fw.c
>>> +++ b/drivers/gpu/drm/panthor/panthor_fw.c
>>> @@ -1336,8 +1336,17 @@ int panthor_fw_init(struct panthor_device *ptdev)
>>>  	}
>>>  
>>>  	ret = panthor_fw_load(ptdev);
>>> -	if (ret)
>>> +	if (ret) {
>>> +		/*
>>> +		 * The firmware in the rootfs will not be accessible until we
>>> +		 * are in the SYSTEM_RUNNING state, so return EPROBE_DEFER until
>>> +		 * that point.
>>> +		 */
>>> +		if (system_state < SYSTEM_RUNNING)
>>
>> This should really only be in the case where ret == -ENOENT - any other
>> error and the firmware is apparently present but broken in some way, so
>> there's no point deferring.
>>
>> I also suspect we'd need some change in panthor_fw_load() to quieten
>> error messages if we're going to defer on this, in which case it might
>> make more sense to move this logic into that function.
>>
> 
> In the thread you referenced I suggested to add that logic in request_firmware()
> (or add a new request_firmware_defer() helper function) that changes the request
> firmare behaviour to return -EPROBE_DEFER instead of -ENOENT.

That would seem like a good feature if it's agreed that deferring on
request_firmware is a good idea.

> Since as you mentioned, this isn't specific to panthor and an issue that I also
> faced with the powervr driver.

I'm not in any way against the idea of deferring the probe until the
firmware is around - indeed it seems like a very sensible idea in many
respects. But I don't want panthor to be 'special' in this way.

If the consensus is that the firmware should live with the module (i.e.
either both in the initramfs or both in the rootfs) then the code is
fine as it is. That seemed to be the view of Sima in that thread and
seems reasonable to me - why put the .ko in the initrd if you can't
actually use it until the rootfs comes along?

The other option is the user fallback mechanisms for firmware loading
which can wait arbitrarily for the firmware to become available. But
that isn't exactly popular these days.

Steve

  reply	other threads:[~2024-04-25 14:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-13 11:49 Andy Yan
2024-04-15  8:46 ` Steven Price
2024-04-25  9:22   ` Javier Martinez Canillas
2024-04-25 14:28     ` Steven Price [this message]
2024-04-25 14:45       ` Javier Martinez Canillas

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=501d18c9-3116-4cd1-8091-b9f552e9fb5a@arm.com \
    --to=steven.price@arm.com \
    --cc=airlied@gmail.com \
    --cc=andy.yan@rock-chips.com \
    --cc=andyshrk@163.com \
    --cc=boris.brezillon@collabora.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=tzimmermann@suse.de \
    /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

all inboxes | Powered by JetHome®