Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>
To: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v3 2/6] drm/i915/pxp: Make intel_pxp_is_enabled implicitly sort PXP-owning-GT
Date: Tue, 15 Nov 2022 05:23:37 +0000	[thread overview]
Message-ID: <86cc7f71007fb08f590f9585b91d2b2c512dd19e.camel@intel.com> (raw)
In-Reply-To: <8722056e-3e6f-8ec6-6586-eaa9711d6b49@intel.com>



On Mon, 2022-11-14 at 20:11 -0800, Ceraolo Spurio, Daniele wrote:
> 
> On 10/21/2022 10:39 AM, Alan Previn wrote:
> > @@ -68,11 +69,34 @@ bool intel_gtpxp_is_supported(struct intel_pxp *pxp)
> >   	return false;
> >   }
> >   
> > -bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
> > +bool intel_gtpxp_is_enabled(const struct intel_pxp *pxp)
> 
> I'd rename this to intel_pxp_is_initialized, that way we don't have 2 
> almost identically named checkers that mean different things (and also 
> avoid the gtpxp prefix).
> 
I disagree - one is a wrapper around the other so i rather DO insist we have the same function-action name in the middle
with a different part of the function name being the qualifier for whether its a global level checker or a gt-level
checker. Perhaps as per last review reply, we can do "intel_pxp_is_enabled" as wrapper around "intel_gt_has_pxp_enabled"
- i think the "enabled" part SHOULD be consistent since one is a wrapper around the other else a new reader will even
more baffled about why "enabled" is different from "initialized" despite trying to get to the same anchor point, "pxp-
>ce".


> >   {
> >   	return pxp->ce;
> >   }
> >   
> > +static struct intel_gt *_i915_to_pxp_gt(struct drm_i915_private *i915)
> 
> nit: why the "_" prefix? we usually don't use it for x_to_y functions. 
> Not a blocker.
I was assuming internal static functions dont have to obey such rules - i like to use _foo for all local static
functions (so that when reading from a caller's code, i know its a local static). Again, just another naming convention
preference thing that i feel seems to be happening here and there in the driver code base but not consistent across all
files / function types. Since its a nit, i won't change this.

> 
> > +{
> > +	struct intel_gt *gt = NULL;
> > +	int i = 0;
> > +
> > +	for_each_gt(gt, i915, i) {
> > +		/* There can be only one GT that supports PXP */
> 
> 
> 
> > +		if (gt && intel_gtpxp_is_supported(&gt->pxp))
> 
> for_each_gt already checks for gt not being NULL, no need to check again.
Got it - will fix this.

> 
> Daniele
> 
> 


  reply	other threads:[~2022-11-15  5:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21 17:39 [Intel-gfx] [PATCH v3 0/6] drm/i915/pxp: Prepare intel_pxp entry points for MTL Alan Previn
2022-10-21 17:39 ` [Intel-gfx] [PATCH v3 1/6] drm/i915/pxp: Make gt and pxp init/fini aware of PXP-owning-GT Alan Previn
2022-11-15  4:00   ` Ceraolo Spurio, Daniele
2022-11-15  5:10     ` Teres Alexis, Alan Previn
2022-11-16 21:41       ` Teres Alexis, Alan Previn
2022-10-21 17:39 ` [Intel-gfx] [PATCH v3 2/6] drm/i915/pxp: Make intel_pxp_is_enabled implicitly sort PXP-owning-GT Alan Previn
2022-11-15  4:11   ` Ceraolo Spurio, Daniele
2022-11-15  5:23     ` Teres Alexis, Alan Previn [this message]
2022-10-21 17:39 ` [Intel-gfx] [PATCH v3 3/6] drm/i915/pxp: Make intel_pxp_is_active " Alan Previn
2022-11-15  4:17   ` Ceraolo Spurio, Daniele
2022-11-15  5:26     ` Teres Alexis, Alan Previn
2022-10-21 17:39 ` [Intel-gfx] [PATCH v3 4/6] drm/i915/pxp: Make PXP tee component bind/unbind aware of PXP-owning-GT Alan Previn
2022-11-15  4:19   ` Ceraolo Spurio, Daniele
2022-10-21 17:39 ` [Intel-gfx] [PATCH v3 5/6] drm/i915/pxp: Make intel_pxp_start implicitly sort PXP-owning-GT Alan Previn
2022-11-15  4:20   ` Ceraolo Spurio, Daniele
2022-10-21 17:39 ` [Intel-gfx] [PATCH v3 6/6] drm/i915/pxp: Make intel_pxp_key_check " Alan Previn
2022-11-15  4:21   ` Ceraolo Spurio, Daniele
2022-10-21 18:34 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Prepare intel_pxp entry points for MTL (rev3) Patchwork
2022-10-22 11:44 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=86cc7f71007fb08f590f9585b91d2b2c512dd19e.camel@intel.com \
    --to=alan.previn.teres.alexis@intel.com \
    --cc=daniele.ceraolospurio@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox