On Mon, Feb 23, 2026 at 04:25:08PM -0600, Bjorn Andersson wrote:
> 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?
Yes.
>
> Note that the fastrpc service is coming and going, as the remoteproc
> starts and stops.
Even one more reason to use drm_device for life cycle management
instead of manually inventing the wheel.
>
> Regards,
> Bjorn
>
> > >
> > > Regards,
> > > Bjorn
> >
> > --
> > With best wishes
> > Dmitry
--
With best wishes
Dmitry
