[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aDYF2cBPdb0EHRrX@black.fi.intel.com>
Date: Tue, 27 May 2025 21:35:05 +0300
From: Raag Jadav <raag.jadav@...el.com>
To: "Usyskin, Alexander" <alexander.usyskin@...el.com>
Cc: Miquel Raynal <miquel.raynal@...tlin.com>,
Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>,
"De Marchi, Lucas" <lucas.demarchi@...el.com>,
Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
"Vivi, Rodrigo" <rodrigo.vivi@...el.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Tvrtko Ursulin <tursulin@...ulin.net>,
"Poosa, Karthik" <karthik.poosa@...el.com>,
"Abliyev, Reuven" <reuven.abliyev@...el.com>,
"Weil, Oren jer" <oren.jer.weil@...el.com>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"intel-xe@...ts.freedesktop.org" <intel-xe@...ts.freedesktop.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Tomas Winkler <tomasw@...il.com>
Subject: Re: [PATCH v10 06/10] drm/i915/nvm: add nvm device for discrete
graphics
On Tue, May 27, 2025 at 11:30:20AM +0530, Usyskin, Alexander wrote:
> > Subject: Re: [PATCH v10 06/10] drm/i915/nvm: add nvm device for discrete
> > graphics
> >
> > On Thu, May 15, 2025 at 04:33:41PM +0300, Alexander Usyskin wrote:
> > > Enable access to internal non-volatile memory on
> > > DGFX devices via a child device.
> > > The nvm child device is exposed via auxiliary bus.
> >
> > ...
> >
> > > +void intel_nvm_init(struct drm_i915_private *i915)
> > > +{
> >
> > Lucas recently revamped xe driver to address this, so let's not hide bugs
> > and return an error where possible.
> >
> I can return error from this call, but the SPI failure is non-fatal for Xe.
> Caller should ignore error from this init.
Fair. Let's atleast return error and leave the handling to the caller,
so we don't have to come back revamping it in the future.
Raag
Powered by blists - more mailing lists