From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 4D8972F618D for ; Tue, 2 Dec 2025 10:12:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764670330; cv=none; b=r4y5kTyotMmWTYL06GvC56jlkpBNGGJWg6Nm6MAEn5v/84PWTKTNV6wTh2fSY3FROQzYHUKP0qx4CQP9EJgYiA9TUe85AeQBFokFMVgGUMyySuqFgWXsMLFOgvhNh0WPZN1qo1VuJBB3DOmJ7vuXk1XnombYFLvHj/pIkHZIvTI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764670330; c=relaxed/simple; bh=Ey5eI3s0EZIjd/ihRfI3/2W1ncKTIRrlw1t8+SMQf1k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=DSLQO6RoJVpCf69N4SuFABLOFxv3QoPOufxFWPLdyWSw8B/UKV6f+vOqTQK4fpCjvzcuO0S4Q9jF3Lwmi2JvcDOxRZba+Dg4xGfjHWp6NCjtvAHKgGx6ngBRGjsMFUGLBSBeBlX2FRe8Y3ytu/FBrURaRedlXq30leDTpKeTrZg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=V4Bm+qah; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="V4Bm+qah" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4779cc419b2so54197715e9.3 for ; Tue, 02 Dec 2025 02:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1764670326; x=1765275126; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=CxYOXKUAxv2oo2iThAzf0N7pfohHkz79DOwp2lJTIMk=; b=V4Bm+qahK1SQl5czdtxfJPW1Uw5t+3ZEkf6qHnk6VuXKTMiFbb+J3/tO+eXIQ3o6LI C0sT+xGuyi3dco11CWiowy7k61jj/WlOsJjIF0B5SZJv2+WvdLVsKJvGMtpwWjBiMSz/ WZD6IJM8LWmbS69frz6wIi6Ft58ENsBxXQqW1eZDBQr9s3k+a+j0BkMPskv/7blPd/9h NhKHbcKo3psx4V5NSBlE8p4tPylrKyofyro8WNXwQ6FJIQo9+V7HsfUsZk7tSx1Wpsi2 T1cdwcfwQmcpLkdeFbTWXAHVOLSaxHV9zxtYTikzquy4bHv8r0vZecOYBAfqkxIiYcer /uiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764670327; x=1765275127; h=content-transfer-encoding:in-reply-to:content-language:from :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=CxYOXKUAxv2oo2iThAzf0N7pfohHkz79DOwp2lJTIMk=; b=qVuRQlIbexFxuqfwtkWyYumcGN+p0HXy7k1BrUo6S55Ma7RB/5mkaXZ8ooXe8/C/62 XLf0R3w44UZELixl1dRQNekv7pFDS02RJoeFnyOcV1l7CkC6cVpeiXLIzKjV8iaOOpS0 RYthYfNpKXVEMjaC+dnxyzqeKQ4N45aLta36s8EvwBhIrcd5LLjxlW1atNnfmhh8hh2j aWpBDjXAcpJFXQx/qz0Zl67/4w6pAZ9YNcmZ9WafwDB28LCmpF0xWfwh5oEccx7gOVhf hDXwsIWxjzFbRvpXD9VBHRfRggrY+JM1S2ldgUHUpMoQHkkIzkFvNlokrjmVG+yzmvtw jdUQ== X-Forwarded-Encrypted: i=1; AJvYcCXtMg0Ha8dlRANUdB1CFIT0o7Iue8M114DewbG1RYr737jUEzKscD7etgDE3hHbi2ClznGcJ0RJjjhZ6GA=@vger.kernel.org X-Gm-Message-State: AOJu0YxXrjS6IlvZNBq3dTk2p0DuVPOsPTR+pUgcGCQ/2VIyyyHq2qe2 vRS7QCUOBiNCcK4fdQQOqDD5cA+D9bHFGnXypHpuHoXZO6bwbShT0y5R2V0EEuTX+TM= X-Gm-Gg: ASbGnctVBgrYPFhqFUXCxRRHM2hm+Dqwz5GAN2BT792S6gWaPaw3BBjrBueqThsSH0W hyXpmcs35DNy/5B+3oTy0fwxVGlYX4h6SZ92AvAAEDni+YpcI/04kACvEc7AYohI+HeIkdQZE/d MuumRqn11OemHWkqe4dhEVer8q09QvRPqKZGXUlJUC5lk09ixVplAV8/u8edL4ydUv4gubCDidQ GcYeiLjAe+YXrGlGSwYocw4M2kqJyD2vb1LQszkBKcCNsJ6A+5/2MDAAHn3RxYSWSJ/ocV3X3Fp xwXj70nfqyg2PUqvsZVXwfVjRlHkAFuJ7orBxSmMkjbjwqPLZ3nmFlJwj+XQGARtBjasu0/d7Rh z5E936l+NuKmW6ONZcwT0GgcD//FzDjB/F+jaMC8tkp2QIxI0SZmUtOFAUCo3bzdpUv4egOPqPt ic6IKBGynsaN/YupbkHHOVYmcgRvc= X-Google-Smtp-Source: AGHT+IEys/A3nKiC2zwVQpwKCOow8VuHIYtsNZJK9C+bNsjFGQrcIjqbb4SZ55KQBpO3EYjRTFFIIA== X-Received: by 2002:a05:600c:4ece:b0:477:7af8:c8ad with SMTP id 5b1f17b1804b1-477c115db0cmr447432975e9.31.1764670326603; Tue, 02 Dec 2025 02:12:06 -0800 (PST) Received: from [192.168.1.221] ([5.31.29.35]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47927a06a09sm10833185e9.16.2025.12.02.02.12.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Dec 2025 02:12:06 -0800 (PST) Message-ID: Date: Tue, 2 Dec 2025 12:12:03 +0200 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: Re: [PATCH] shdmac: Remove misleading TODO comment in dmae_set_chcr To: Amin GATTOUT , vkoul@kernel.org, thomasandreatta2000@gmail.com Cc: dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org References: <20251128152947.304976-2-amin.gattout@gmail.com> From: Eugen Hristev Content-Language: en-US In-Reply-To: <20251128152947.304976-2-amin.gattout@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/28/25 17:29, Amin GATTOUT wrote: > The comment suggested that the dmae_is_busy() check in dmae_set_chcr() > is superfluous and could be removed. However, this check serves as an > important safety net to prevent configuration of a DMA channel while I find this a bit odd overall, because apparently nobody checks the result of dmae_set_chcr() . So if it is such an important safety check, why is the result never checked ? As it looks, the caller doesn't care and continue as usual. The difference would be that chcr is never actually written if the channel is busy. Which looks strange. And "unexpected hardware behavior in edge cases" is quite vague. Do you have a scenario when an issue would happen ? dmae_set_chcr() gets called on resume() and setup_xfer(). Is it possible that in fact dmae_set_chcr() is not called correctly then ? Maybe this chcr should be written at a different time when we are sure the dma is not busy ? Or why is it even possible to have the dma busy when calling it ? Eugen > it is active. Keeping it helps ensure transfer integrity and avoids > unexpected hardware behavior in edge cases. > > Signed-off-by: Amin GATTOUT > --- > drivers/dma/sh/shdmac.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/dma/sh/shdmac.c b/drivers/dma/sh/shdmac.c > index 603e15102e45..d0e0437ad916 100644 > --- a/drivers/dma/sh/shdmac.c > +++ b/drivers/dma/sh/shdmac.c > @@ -243,7 +243,6 @@ static void dmae_init(struct sh_dmae_chan *sh_chan) > > static int dmae_set_chcr(struct sh_dmae_chan *sh_chan, u32 val) > { > - /* If DMA is active, cannot set CHCR. TODO: remove this superfluous check */ > if (dmae_is_busy(sh_chan)) > return -EBUSY; >