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