All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raag Jadav <raag.jadav@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org,
	Matt Roper <matthew.d.roper@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Francois Dugast <francois.dugast@intel.com>,
	Maarten Lankhorst <dev@lankhorst.se>
Subject: Re: [PATCH 5/7] drm/xe: Cleanup unwind of gt initialization
Date: Sun, 2 Feb 2025 10:09:21 +0200	[thread overview]
Message-ID: <Z58oMTJcu1E0WiCK@black.fi.intel.com> (raw)
In-Reply-To: <lliho4ci6gi5spxxelttgqntbh7rxr4utg4dgfevlrdy54phrh@2k4mjuofaqye>

On Sat, Feb 01, 2025 at 09:55:47AM -0600, Lucas De Marchi wrote:
> On Sat, Feb 01, 2025 at 08:24:50AM +0200, Raag Jadav wrote:
> > On Fri, Jan 31, 2025 at 02:31:38PM -0800, Lucas De Marchi wrote:
> > > Move the xe_gt_remove() to be handled by xe_gt.c itself so the caller,
> > > xe_device_probe() doesn't have to unwind the gt loop. It's also more in
> > > line with the xe_device_probe() style.
> > > 
> > > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > > ---
> > >  drivers/gpu/drm/xe/xe_device.c | 21 ++-----------------
> > >  drivers/gpu/drm/xe/xe_gt.c     | 37 ++++++++++++++++------------------
> > >  drivers/gpu/drm/xe/xe_gt.h     |  1 -
> > >  3 files changed, 19 insertions(+), 40 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> > > index e519f435b1606..bea626f6b4cbf 100644
> > > --- a/drivers/gpu/drm/xe/xe_device.c
> > > +++ b/drivers/gpu/drm/xe/xe_device.c
> > > @@ -743,7 +743,6 @@ int xe_device_probe(struct xe_device *xe)
> > >  	struct xe_tile *tile;
> > >  	struct xe_gt *gt;
> > >  	int err;
> > > -	u8 last_gt;
> > >  	u8 id;
> > > 
> > >  	xe_pat_init_early(xe);
> > > @@ -851,18 +850,16 @@ int xe_device_probe(struct xe_device *xe)
> > >  		return err;
> > > 
> > >  	for_each_gt(gt, xe, id) {
> > > -		last_gt = id;
> > > -
> > >  		err = xe_gt_init(gt);
> > >  		if (err)
> > > -			goto err_fini_gt;
> > > +			return err;
> > 
> > So it's either all or nothing? Can't we operate with atleast what we have?
> 
> it was already like that, this is just moving the check to be in a
> better place.
> 
> But yes, we've decided long ago that it's better to fail early and fix
> it rather than having semi-working driver in production.

Sure, makes sense.

Reviewed-by: Raag Jadav <raag.jadav@intel.com>

  reply	other threads:[~2025-02-02  8:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-31 22:31 [PATCH 0/7] Cleanup error handling on probe Lucas De Marchi
2025-01-31 22:31 ` [PATCH 1/7] drm/xe: Fix xe_display_fini() calls Lucas De Marchi
2025-02-03 20:32   ` Rodrigo Vivi
2025-01-31 22:31 ` [PATCH 2/7] drm/xe: Fix error handling in xe_irq_install() Lucas De Marchi
2025-02-03 20:36   ` Rodrigo Vivi
2025-01-31 22:31 ` [PATCH 3/7] drm/xe: Fix xe_tile_init_noalloc() error propagation Lucas De Marchi
2025-02-03 14:21   ` Francois Dugast
2025-01-31 22:31 ` [PATCH 4/7] drm/xe: Stop ignoring errors from xe_ttm_stolen_mgr_init() Lucas De Marchi
2025-02-03 14:10   ` Francois Dugast
2025-01-31 22:31 ` [PATCH 5/7] drm/xe: Cleanup unwind of gt initialization Lucas De Marchi
2025-02-01  6:24   ` Raag Jadav
2025-02-01 15:55     ` Lucas De Marchi
2025-02-02  8:09       ` Raag Jadav [this message]
2025-01-31 22:31 ` [PATCH 6/7] drm/xe: Cleanup extra calls to xe_hw_fence_irq_finish() Lucas De Marchi
2025-02-03 21:46   ` Rodrigo Vivi
2025-01-31 22:31 ` [PATCH 7/7] drm/xe: Move oa fini to xe_oa Lucas De Marchi
2025-01-31 22:37 ` ✓ CI.Patch_applied: success for Cleanup error handling on probe Patchwork
2025-01-31 22:37 ` ✓ CI.checkpatch: " Patchwork
2025-01-31 22:38 ` ✓ CI.KUnit: " Patchwork
2025-01-31 22:55 ` ✓ CI.Build: " Patchwork
2025-01-31 22:57 ` ✓ CI.Hooks: " Patchwork
2025-01-31 22:59 ` ✓ CI.checksparse: " Patchwork
2025-01-31 23:32 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-02-01  8:05 ` ✗ Xe.CI.Full: " Patchwork
2025-02-03 18:39 ` [PATCH 0/7] " Lucas De Marchi
2025-02-04  8:58 ` Tvrtko Ursulin
2025-02-04 14:50   ` Lucas De Marchi
2025-02-04 18:10     ` Tvrtko Ursulin
2025-02-04 22:42       ` Rodrigo Vivi

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=Z58oMTJcu1E0WiCK@black.fi.intel.com \
    --to=raag.jadav@intel.com \
    --cc=dev@lankhorst.se \
    --cc=francois.dugast@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=rodrigo.vivi@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 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.