All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Dave Gordon <david.s.gordon@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 1/4] drm/i915/guc: symbolic names for GuC submission preferences
Date: Tue, 02 Aug 2016 10:23:46 +0300	[thread overview]
Message-ID: <874m73tz0d.fsf@intel.com> (raw)
In-Reply-To: <62a35c6f-bf7a-03ba-9f7e-4ae34dfd6c12@intel.com>

On Mon, 01 Aug 2016, Dave Gordon <david.s.gordon@intel.com> wrote:
> On 01/08/16 14:54, Jani Nikula wrote:
>> On Fri, 22 Jul 2016, Dave Gordon <david.s.gordon@intel.com> wrote:
>>> -	} else if (i915.enable_guc_submission > 1) {
>>> +	} else if (i915.enable_guc_submission >= GUC_SUBMISSION_MANDATORY) {
>>
>> I like the patches in general, but now these >= and <= seem rather out
>> of place. How about using == and != exclusively?
>>
>> BR,
>> Jani.
>
> That would leave us with undefined behaviour for values outside the 
> recognised range. This way it clips out-of-range values to the nearest 
> extremum. Of course we could make it fail completely for invalid values, 
> but that's just really annoying for the developer or admin who's 
> mistyped -1 as -2 or forgotten what the maximum supported value is in 
> this release. Alternatively we could convert all out-of-range values to 
> "system default" i.e. ignored, which might still be annoying but not 
> quite as much.

I'm not a huge fan of making assumptions about what the user possibly
meant when giving incorrect input, "as a convenience". It teaches the
user to be sloppy about it, and might lead to super annoying surprises
when we actually start using those values for something else.

> Any other suggestions for how to handle out-of-range values?
>
> But if we were changing the policy shouldn't that be a separate patch? 
> This patch is supposed to change only the way the code is written, with 
> no effect to existing behaviour!

Oh, completely agreed here, while I didn't spell this out in my first
reply. This shouldn't block the patch.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-08-02  7:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-22 13:32 [PATCH v3 0/4] drm/i915/guc: use symbolic names for module parameter values Dave Gordon
2016-07-22 13:32 ` [PATCH v3 1/4] drm/i915/guc: symbolic names for GuC submission preferences Dave Gordon
2016-08-01 13:54   ` Jani Nikula
2016-08-01 18:57     ` Dave Gordon
2016-08-02  7:23       ` Jani Nikula [this message]
2016-08-02  9:47       ` Dave Gordon
2016-07-22 13:32 ` [PATCH v3 2/4] drm/i915/guc: symbolic names for GuC firmare loading preferences Dave Gordon
2016-07-22 13:32 ` [PATCH v3 3/4] drm/i915/guc: symbolic name for GuC log-level none Dave Gordon
2016-07-22 13:32 ` [PATCH v3 4/4] drm/i915/guc: use symbolic names in setting defaults for module parameters Dave Gordon
2016-07-22 14:02 ` ✗ Ro.CI.BAT: warning for drm/i915/guc: use symbolic names for module parameter values Patchwork

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=874m73tz0d.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=david.s.gordon@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.