From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C58443DA20 for ; Fri, 4 Sep 2026 10:40:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788518432; cv=none; b=NLb70b1zlgeu4un2eQn4J9q67+ku2O7y8DLfPrT03M33ZDyS3qlJBcE5MzuXA7UgJ8fSHbD8d/vVa2zOyp+c/WLa1lKSCYbvNf5j8m6SobINiaS2gPx4jjeE9kcjD8mYe0DceWvqMw8hYqgNgR8p5tFe4V3Zq3Ikt2JzTZYvuOo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788518432; c=relaxed/simple; bh=X+IPOeHqJEE/pPReJUqA9P+8xBHbJ/fYKeigiadbp7g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JbWpeoyAjIQL8AiYFkdYIIex2zHhRDq5NJR4qzKxJKcDOibXNIXwGm0Z5Lt4gOsDNjGsl8SKNDm6F004rzsBzm1JiPLP8P1gITbUBBC8RVxm5mfOkE13Tp0XUlR6zz1YNvfCBCSxaRaxRCGQDrX4Lf4ObtLmqChZvAOukpMlHIY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=FydX/T61; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="FydX/T61" Received: from ideasonboard.com (unknown [93.65.100.155]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id E123A2023; Fri, 4 Sep 2026 12:38:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1788518329; bh=X+IPOeHqJEE/pPReJUqA9P+8xBHbJ/fYKeigiadbp7g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FydX/T61S0jimF2id9F4VcDHpBjeSuBtq+1PB4nrTTGdgU4+oGWhjlpAAj0/uj58v 0+e3igBUokRO2MDvBbphT2ztWMYdgfPcSUam9dJNl/bTvl6GZsQbms1ebyyRAJElL1 bml46FfaiYPGOrZSHoZ4+DU7VZbCqNkX/Neo/Qm8= Date: Fri, 4 Sep 2026 12:40:18 +0200 From: Jacopo Mondi To: Linus Walleij Cc: Li Youhong , dan.scally@ideasonboard.com, jacopo.mondi@ideasonboard.com, mchehab@kernel.org, linux-media@vger.kernel.org, Li Youhong Subject: Re: [PATCH] media: mali-c55: free IRQ when remove while runtime-active Message-ID: References: <20260903025526.2657105-1-dayou5941@163.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi Linus On Fri, Sep 04, 2026 at 12:12:20PM +0200, Linus Walleij wrote: > On Thu, Sep 3, 2026 at 4:55 AM Li Youhong wrote: > > > @@ -861,6 +861,8 @@ static void mali_c55_remove(struct platform_device *pdev) > > > > mali_c55_media_frameworks_deinit(mali_c55); > > if (!pm_runtime_suspended(&pdev->dev)) { > > + if (irq_has_action(mali_c55->irqnum)) > > + free_irq(mali_c55->irqnum, &pdev->dev); > > __mali_c55_power_off(mali_c55); > > pm_runtime_set_suspended(&pdev->dev); > > This whole runtime suspend/resume looks a bit odd to me. > > Normally you keep the IRQ requested perpetually in a driver, > this looks like some really odd workaround to explicitly deal with > wakeup capable/non-wakeup capable IRQs. > > I tried to see if this was addressed during review of the driver > and whether there was a reason for doing things like this. > But there are too many threads on lore. Indeed it's weird. I've a branch that I started that tried to fix that, but the issue I was hitting was due the fact the ISP starts with all ISP unmasked, and I get very bad races between the power-up routine and the IRQ. I run out of time and gave up, but if you're interested I can provide you references to that work > > I think the proper fix is to keep the IRQ requested during > suspend/resume and *not* mark it as wakeup-source; in the > device tree for the SoC. > > Support code is needed in the driver, something along the line > of this: > > suspend(): > if (device_may_wakeup(dev)) > enable_irq_wake(irq); > > resume(): > if (device_may_wakeup(dev)) > disable_irq_wake(irq); > > Do you want to make the patch or should I? That's something I didn't consider maybe :) > > Yours, > Linus Walleij