Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Nirmoy Das <nirmoy.das@linux.intel.com>
To: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Cc: Andi Shyti <andi.shyti@intel.com>,
	intel-xe@lists.freedesktop.org, Nirmoy Das <nirmoy.das@intel.com>
Subject: Re: [Intel-xe] [PATCH V2] drm/xe: make GT sysfs init return void
Date: Wed, 5 Jul 2023 18:37:46 +0200	[thread overview]
Message-ID: <29fe7224-92e8-0f62-6801-b2588dbb1001@linux.intel.com> (raw)
In-Reply-To: <87wmzecqd6.wl-ashutosh.dixit@intel.com>

Hi Ashutosh,

On 7/5/2023 5:47 PM, Dixit, Ashutosh wrote:
> On Wed, 05 Jul 2023 08:39:20 -0700, Nirmoy Das wrote:
>> Hi Ashutosh,
>>
>> On 7/5/2023 4:06 PM, Dixit, Ashutosh wrote:
>>> On Wed, 05 Jul 2023 01:44:03 -0700, Tejas Upadhyay wrote:
>>>> Currently return from xe_gt_sysfs_init() is ignored
>>>> and also a failure in xe_gt_sysfs_init() isn't fatal
>>>> so make it return void.
>>> But why is the failure not fatal? I really don't understand the concept of
>>> these non-fatal failures. Do we really want to say the device is up if
>>> sysfs initialization has failed for some reason and people are unable to
>>> see card freq's e.g.? This was done in i915 but do we really want to repeat
>>> this for xe? IMO the simplest thing to do would be to fail the probe unless
>>> ALL required/intended functionality is clearly up.
>>
>> I agree with the concern but the situation is different with a graphics
>> driver.
>>
>> If we return error on probe, (if I am not wrong) a user will have no way to
>> interact
>>
>> with the system other than ssh. We should ignore non-fatal error and let
>> the driver load
>>
>> so a user can have something to work with(may be report a bug :) )
> Hmm, good point. Agreed :)
>
> This way though only display is critical and everything else non-critical?

Yes, that would be wrong, I am not saying that. We do return error 
during the probe at multiple locations,

I believe we can prioritize system usability by considering this 
specific error as non-critical. Although those sysfs files are important,

the device should still usable without them.


Thanks,

Nirmoy

> My point was knowing (or controlling) GPU freq's is a pretty important part
> of doing work on the GPU.
>
> In any case, since we are printing an error in dmesg if sysfs init fails,
> maybe converting to void is ok. So this is:
>
> Acked-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
>
>>
>> Regards,
>>
>> Nirmoy
>>
>>> Instead of ignoring the return, fail the probe?
>>>
>>> Thanks.
>>> --
>>> Ashutosh

  reply	other threads:[~2023-07-05 16:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-05  8:44 [Intel-xe] [PATCH V2] drm/xe: make GT sysfs init return void Tejas Upadhyay
2023-07-05  9:52 ` [Intel-xe] ✓ CI.Patch_applied: success for " Patchwork
2023-07-05  9:52 ` [Intel-xe] ✓ CI.checkpatch: " Patchwork
2023-07-05  9:53 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-07-05  9:57 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-07-05  9:57 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-07-05  9:59 ` [Intel-xe] ✓ CI.checksparse: " Patchwork
2023-07-05 14:06 ` [Intel-xe] [PATCH V2] " Dixit, Ashutosh
2023-07-05 14:27   ` Upadhyay, Tejas
2023-07-05 15:39   ` Nirmoy Das
2023-07-05 15:47     ` Dixit, Ashutosh
2023-07-05 16:37       ` Nirmoy Das [this message]
2023-07-11 10:42         ` Andi Shyti
2023-07-11 15:23           ` Dixit, Ashutosh

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=29fe7224-92e8-0f62-6801-b2588dbb1001@linux.intel.com \
    --to=nirmoy.das@linux.intel.com \
    --cc=andi.shyti@intel.com \
    --cc=ashutosh.dixit@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=nirmoy.das@intel.com \
    /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