Re: [PATCH RFC 03/18] accel/qda: Add RPMsg transport for Qualcomm DSP accelerator

[Bjorn Andersson]

On Tue, Feb 24, 2026 at 12:12:32AM +0200, Dmitry Baryshkov wrote:
> On Mon, Feb 23, 2026 at 03:50:32PM -0600, Bjorn Andersson wrote:
> > On Mon, Feb 23, 2026 at 11:23:13PM +0200, Dmitry Baryshkov wrote:
> > > On Tue, Feb 24, 2026 at 12:38:57AM +0530, Ekansh Gupta wrote:
> > [..]
> > > > diff --git a/drivers/accel/qda/qda_drv.h b/drivers/accel/qda/qda_drv.h
> > [..]
> > > > +/* Error logging - always logs and tracks errors */
> > > > +#define qda_err(qdev, fmt, ...) do { \
> > > > +	struct device *__dev = qda_get_log_device(qdev); \
> > > > +	if (__dev) \
> > > > +		dev_err(__dev, "[%s] " fmt, __func__, ##__VA_ARGS__); \
> > > > +	else \
> > > > +		pr_err(DRIVER_NAME ": [%s] " fmt, __func__, ##__VA_ARGS__); \
> > > 
> > > What /why? You are under drm, so you can use drm_* helpers instead.
> > > 
> > 
> > In particular, rather than rolling our own wrappers around standard
> > functions, just use dev_err() whenever you have a struct device. And for
> > something like fastrpc - life starts at some probe() and ends at some
> > remove() so that should be always.
> 
> I'd say differently. For the DRM devices the life cycle is centered
> around the DRM device (which can outlive platform device for multiple
> reasons). So, please start by registering the DRM accel device and using
> it for all the logging (and btw for private data management too).
> 

There are no platform_devices here, but tomato tomato... What defines
the life cycle of the DRM device then? Might it linger because clients
are holding open handles to it?

Note that the fastrpc service is coming and going, as the remoteproc
starts and stops.

Regards,
Bjorn

> > 
> > Regards,
> > Bjorn
> 
> -- 
> With best wishes
> Dmitry