From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1216F2C0303 for ; Mon, 20 Apr 2026 12:33:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776688396; cv=none; b=dksnt6aklWmUceIHf3UthJXXk9S1tUPhEY6qrrhx1t4aDmdsWzaHjJiizlZDUud68oIYMgB6j4iDHEeqgnslqdsXTqgk5pNhFBukIfhXkQ5oVpCmHou78wywMrw9N4S98yIYianjRyBpT47ydzAM8QaDuf5kpGjc+HDe4u6SwUU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776688396; c=relaxed/simple; bh=ouN2T9zodtnGRFKEDJT3a7cOKWhNDFwWELKSz0rhc0w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WYxv4n7boT2kZ6bfs+XWaUKGVErWGFuJJoOu1Q+hdH+mMhcHVEqeT0Otb2B1YHSypoRPANuSD2qgZ105tZ7c+2CSkjjTHQSFYdObXobetDIXdiOMaQTUP/OyYMA9cHOYpU9M1WDAT+8CmVeaw9TH0DC2/98wYXNHET91Eh7trTg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tuxon.dev; spf=pass smtp.mailfrom=tuxon.dev; dkim=pass (2048-bit key) header.d=tuxon.dev header.i=@tuxon.dev header.b=M1N0OqMk; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tuxon.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=tuxon.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=tuxon.dev header.i=@tuxon.dev header.b="M1N0OqMk" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4891e86fabeso9891645e9.1 for ; Mon, 20 Apr 2026 05:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxon.dev; s=google; t=1776688391; x=1777293191; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=vywUgRyvHiyb8Tcpyclkx71VYCcveacoMI82OHms9l8=; b=M1N0OqMk+uWjKQRIYI0OyaTX1K8F2HmFCZf0WT5zTHMJ9P4bOboGbYPJWlDshk26Aw s+F90I7mPz/s4+9m0EUo+2xz3iUHpFmVr2aim/zzgQl8qZCH3sV5IKBJzcChN9Hrj3Or sSwLuXJ2CarFRej+ezqVLRYDii8q9XfnKpFC7s5ejsqwwplFODD86mgY7jHoRIQ1eJmC P8tlxFSaoeyb0aK+5Ifl5uzyW9TN++KrwaXU2qgkRKjIKuQNeCjz6UKOv3CWnnKR7jtF F08kVcN87RJU5ensJMu12/D/krZQqcAgSgBGjLk5hrf41gfvAQ8EQY3emDgOjlI5OD34 NbVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776688391; x=1777293191; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vywUgRyvHiyb8Tcpyclkx71VYCcveacoMI82OHms9l8=; b=jdtrEgv2GZ0uH4fx6WaohKHmNrYiGiyVs5ZayS9/m7X+RzlYN2nSD1/KbD5wtJ3E7I qb/SQqRklE6KJfAtUhSqqr+F32NZQldnvH+tTYsLuYyTeUN/7bwIFvVCxVwDDq68murf aE3l5hOj3XyixqyAwl74bvud5ULzPDqUByeXDSEOVrtGyT0dKAoExYEkn25tiiUjjUYi VLapBQWNsmDvhAM7+Q5LixNdkpoVohbSB4E2aRRGOPpP4h3kGFtUm+jT8WUnCDtYJxDe T1q91z2zb/iX9cWo4dtSHxNMxiwdvulECAWa9w7mny+qSW9F5xbd2jKzVA8xodcX80vp 0t5Q== X-Forwarded-Encrypted: i=1; AFNElJ+4w3i0iYvNL41YCPS9J3NCwdhyALth1enE06z+KY6beX6lBw5rR2YX86fGrQNrnzMULN2nolT65Ij/zhI=@vger.kernel.org X-Gm-Message-State: AOJu0YwuXpy9Oppu1z/Wu2j6OSqHU3dn8MMmRRPtoVTbwZgFoClR6t2d NrwK0iKX8/1g6hFa/Z4lHxUW3PZbe9w5D7GnGseMYV8mxTMt3Cq5sJ7Ynaf6TYLycGg= X-Gm-Gg: AeBDiet/MOV8z1NJ4coum5+JHSIaN4olZXN1D137rpywqL/+Qk8doTTcjLKgoGaHmkn Kas0XJbxlJYaE5WC6nVdD9adh4F6QUiso2GnS6fFro/V2OTXNmuAGOav5QsY10uyYW1nL5O2+cH O2hOO3/lUAi61qdGy6NlhB/uzf4UVt7ZNQcV/F88ai7lUZuZw3Mn2Tg1Wk43hjV2W1V8eedFrVg iW0hQArFhgM0wiWfT9hSaRMqrMHGzdYm70+lcp351EPpzmFiRCAyRPrchbzH/yDys4uulraW2XB abwCyWoNZIOJz0WwvOyQYGZktXo57NrkKhyGJ1GiwFsqaSbzBz0lu5Jr2Loq7MYj3nZGAVAPR0Y SRh6XxM2hbLTey4coijX3VEt9VPdf8zkecH+rhd7iOAs2hx0XKQAZpdfIP7Vd26Fi+srNy/k/o0 cWNyDJyh2vHkB4LtVnIAoYan1HtH4TEXAOUsIl8AJ/ig== X-Received: by 2002:a05:600c:8582:b0:486:fab9:a578 with SMTP id 5b1f17b1804b1-488fb7556b9mr147084635e9.11.1776688391119; Mon, 20 Apr 2026 05:33:11 -0700 (PDT) Received: from [192.168.50.4] ([82.78.167.123]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a52583fe7sm19933615e9.13.2026.04.20.05.33.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Apr 2026 05:33:10 -0700 (PDT) Message-ID: <631893a8-d5de-49f8-9d7b-a20db4a8ed08@tuxon.dev> Date: Mon, 20 Apr 2026 15:33:09 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: sashiko.dev review (Re: [PATCH v4 01/17] dmaengine: sh: rz-dmac: Move interrupt request after everything is set up) To: vkoul@kernel.org, Frank.Li@kernel.org, lgirdwood@gmail.com, broonie@kernel.org, perex@perex.cz, tiwai@suse.com, biju.das.jz@bp.renesas.com, prabhakar.mahadev-lad.rj@bp.renesas.com, p.zabel@pengutronix.de, geert+renesas@glider.be, fabrizio.castro.jz@renesas.com, long.luu.ur@renesas.com Cc: dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, linux-sound@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Claudiu Beznea , stable@vger.kernel.org References: <20260411114303.2814115-1-claudiu.beznea.uj@bp.renesas.com> <20260411114303.2814115-2-claudiu.beznea.uj@bp.renesas.com> Content-Language: en-US From: Claudiu Beznea In-Reply-To: <20260411114303.2814115-2-claudiu.beznea.uj@bp.renesas.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > commit b3dfdd5fbd2463db407b1396ee1ae79801cb96bf > Author: Claudiu Beznea > dmaengine: sh: rz-dmac: Move interrupt request after everything is set up > This patch moves the channel interrupt request to the end of the channel > probe function to prevent the IRQ handler from accessing uninitialized > data. It also replaces dma_alloc_coherent() with dmam_alloc_coherent() > to simplify the error path. > > diff --git a/drivers/dma/sh/rz-dmac.c b/drivers/dma/sh/rz-dmac.c > > index 625ff29024de0..9f206a33dcc6b 100644 > > --- a/drivers/dma/sh/rz-dmac.c > > +++ b/drivers/dma/sh/rz-dmac.c > [ ... ] > > @@ -1210,16 +1207,6 @@ static int rz_dmac_probe(struct platform_device *pdev) > > dma_register_err: > > of_dma_controller_free(pdev->dev.of_node); > > err: > > - channel_num = i ? i - 1 : 0; > > - for (i = 0; i < channel_num; i++) { > > - struct rz_dmac_chan *channel = &dmac->channels[i]; > > - > > - dma_free_coherent(&pdev->dev, > > - sizeof(struct rz_lmdesc) * DMAC_NR_LMDESC, > > - channel->lmdesc.base, > > - channel->lmdesc.base_dma); > > - } > > - > > reset_control_assert(dmac->rstc); > > err_pm_runtime_put: > > pm_runtime_put(&pdev->dev); > > @@ -1232,18 +1219,9 @@ static int rz_dmac_probe(struct platform_device *pdev) > > static void rz_dmac_remove(struct platform_device *pdev) > > { > > struct rz_dmac *dmac = platform_get_drvdata(pdev); > > - unsigned int i; > > > > dma_async_device_unregister(&dmac->engine); > > of_dma_controller_free(pdev->dev.of_node); > > - for (i = 0; i < dmac->n_channels; i++) { > > - struct rz_dmac_chan *channel = &dmac->channels[i]; > > - > > - dma_free_coherent(&pdev->dev, > > - sizeof(struct rz_lmdesc) * DMAC_NR_LMDESC, > > - channel->lmdesc.base, > > - channel->lmdesc.base_dma); > > - } > > reset_control_assert(dmac->rstc); > > pm_runtime_put(&pdev->dev); > > pm_runtime_disable(&pdev->dev); > > } > While this patch fixes the initialization races, does it leave a similar > vulnerability exposed during teardown? > Since devm_request_threaded_irq() is used to allocate the interrupts, they > will remain active until after rz_dmac_remove() and the rz_dmac_probe() error > paths complete. > If an interrupt fires during or just after rz_dmac_remove(), could the handler > attempt to access hardware registers while the device is in reset or powered > down by pm_runtime_put()? > Would it be safer to explicitly free or disable the IRQs before asserting the > hardware reset and disabling runtime PM, or perhaps manage the reset and PM > states via devm actions to guarantee correct teardown ordering? On either failure or remove path the device is with runtime PM put (clocks being disabled) and in reset state. The controller cannot generate interrupts from this state. However, to keep this series simple, I'll add this in a cleanup patch after the current series will be merged.