From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E1C83EEC2A0 for ; Mon, 23 Feb 2026 22:25:14 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 41C0010E31E; Mon, 23 Feb 2026 22:25:14 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="XtqRmn6s"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4844C10E31E for ; Mon, 23 Feb 2026 22:25:13 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 0795341A8B; Mon, 23 Feb 2026 22:25:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3EE5BC116C6; Mon, 23 Feb 2026 22:25:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771885512; bh=wfg4VRQE5OBvnbfLt0WHzLC4rvZAYdoLxo98gn+3YZ0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XtqRmn6sXzxFhXP8E1IfC+idVmhuk6RUIOBACSkm8U+6774jsU0QDnOUnd+IxaDbn YUtMJccEZHsa+M/i6Lpr8CyXFcryxYRuwtRBtpNgAEWqIcv1Ec45o3CHJ7qpjfyCzd T+DQp8mMgCp2ELMj037MUXQZbdO8AvpA1Jb5KxKf+ukIMRNAY1/dQhePyW7jSaWNl8 Ql9cNguaVf3Q8b/Lw9d8xi52N3OPFD3kAOSKKe0WJa7CqFIymNvuiPUoABLoBIp/ce 9Pc1lacSracywRFZSsWniAQ1LIM0cjNqajIIxbnGgU5hwzNuDorYyN8tjmXkewdouL XHI3edGwUpc7Q== Date: Mon, 23 Feb 2026 16:25:08 -0600 From: Bjorn Andersson To: Dmitry Baryshkov Cc: Ekansh Gupta , Oded Gabbay , Jonathan Corbet , Shuah Khan , Joerg Roedel , Will Deacon , Robin Murphy , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Sumit Semwal , Christian =?utf-8?B?S8O2bmln?= , dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, iommu@lists.linux.dev, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, Srinivas Kandagatla , Bharath Kumar , Chenna Kesava Raju Subject: Re: [PATCH RFC 03/18] accel/qda: Add RPMsg transport for Qualcomm DSP accelerator Message-ID: References: <20260224-qda-firstpost-v1-0-fe46a9c1a046@oss.qualcomm.com> <20260224-qda-firstpost-v1-3-fe46a9c1a046@oss.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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