Re: [PATCH v4 01/13] drm/xe: Add callback support for driver remove

[Raag Jadav <raag.jadav@intel.com>]

On Wed, Feb 12, 2025 at 03:28:15PM -0600, Lucas De Marchi wrote:
> On Wed, Feb 12, 2025 at 11:19:22PM +0200, Raag Jadav wrote:
> > On Wed, Feb 12, 2025 at 11:35:48AM -0800, Lucas De Marchi wrote:
> > > xe device probe uses devm cleanup in most places. However there are a
> > > few cases where this is not possible: when the driver interacts with
> > > component add/del. In that case, the resource group would be cleanup
> > > while the entire device resources are in the process of cleanup.  One
> > > example is the xe_gsc_proxy and display using that to interact with mei
> > > and audio.
> > > 
> > > Add a callback-based remove so the exception doesn't make the probe
> > > use multiple error handling styles.
> > > 
> > > v2: Change internal API to mimic the devm API. This will make it easier
> > >     to migrate in future when devm can be used.
> > 
> > Which means we'd like to go back to devm action someday, or is that even
> > possible? Assuming it is, and still worth it, why not try to do that
> > instead?
> 
> From the cover letter:
> 	I have other changes on top of these that will make devm compatible.
> 	That will need some drivers/base/ changes though, so it's probably good
> 	to do it in parallel.
> 
> From my reply to Rodrigo:
> 	The devm part is here:
> 	https://lore.kernel.org/dri-devel/20250212200542.515493-1-lucas.demarchi@intel.com/
> 
> 	In the end I could simplify it much more than I thought and what is
> 	required on devres side is just one patch, 2 lines diff. Hopefully I
> 	didn't simplify it too much. Let's see. If that one is accepted through
> 	intel-xe tree, then we may even drop this first patch and go straight
> 	with that solution.
> 
> 	...
> 
> 	I will wait some feedback on that other series to see how we are going
> 	to proceed. If we keep this patch, then I will update this doc.
> 
> I hope this clarifies,

Yep, just trying to weigh in.

Side note: There's a devres.h split in progress[1]. In case you'll be touching
these in future versions, please let me know. We'll do it in a cleaner way that
doesn't conflict.

[1] https://lore.kernel.org/r/20250212062513.2254767-1-raag.jadav@intel.com/

Raag