From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) (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 195B427D786 for ; Fri, 2 Jan 2026 15:42:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767368554; cv=none; b=t/sg5Hr2ZgTNSOdwsTfO0xkkKNJNG9cxHeSNAnQRX47upa9noDRUlQO5DGUZOqSjYkBjJvNV1kTWDpxvnTx/NjETNaLPRnkPAa+YdYNDK2Xpf8OA6FPHt783CvkWNhUGTFVQQRRWt+eWN/XGdYvcqWRACKTHydLewALVRowUWUo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767368554; c=relaxed/simple; bh=9fLuRCFFMaVEtZXeKLAir+rC4rOYTMPaqOnYEmL1WAQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=V7YbFLTrq1cqhr3MCw0QmBTJ4oI2KHI2PGavpA6oONItIBU/lbv1WQrPMJKqlbx2g602lx5E/b0iBGXTJmJXipvGg+6rL/9I8+KDDUv9cIvyMdPaiXEV5CQRUP+OmWJaYneBG8gn6vL69EwYrqw91o0sGflsLXUkgJGNeZVtk90= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com; spf=pass smtp.mailfrom=riscstar.com; dkim=pass (2048-bit key) header.d=riscstar-com.20230601.gappssmtp.com header.i=@riscstar-com.20230601.gappssmtp.com header.b=kbrtT95e; arc=none smtp.client-ip=209.85.160.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=riscstar.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=riscstar-com.20230601.gappssmtp.com header.i=@riscstar-com.20230601.gappssmtp.com header.b="kbrtT95e" Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-4f1b4bb40aaso66057951cf.3 for ; Fri, 02 Jan 2026 07:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=riscstar-com.20230601.gappssmtp.com; s=20230601; t=1767368551; x=1767973351; 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=XUaW410yZnjl46gYHFzLMVokQz6be6dGpRuwVbnPCzc=; b=kbrtT95e5kziTXjrTYZFx38KaA2sWIhpZVjIdtQvHGcIrTqmZ5BatiDXwgMtNKROFB YkNijpVHcAruublw5D9aEhEkX/M8NzlPspeHSd0+r2l0Qb8V4JuhO8ZQUa9vbV59wL4Z fg6dkYWXFrEDycnlGlcLeoPi9F7U6SlX2wnve7GYSbqrswW1hs0CfKT0CCW8csgfczrn rbnctGuVXWa9YbDqj8cmk6hPpvHlP+agUhRb6ih1xlXDEuaF08Ofs5cjKWtFlrMc+Pa1 XpA1yd9jgKNvr0+GpuYPXs2qqUBUFVFp7H/fEBuxzW4oIMIRrXc9u9la3rKvRUiuln4f 7AGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767368551; x=1767973351; 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=XUaW410yZnjl46gYHFzLMVokQz6be6dGpRuwVbnPCzc=; b=AglyvcJp5a1s076qdpXjLhNTsla3Mm5B9v/KS+j35j3jzdp5TGRz6lB5zbcycPG8x4 j06tVUoJKDUuydbHYUa7Ul4iXmijzrDVjFmQgSlSHTgA6X6+dH9HGEYc1sepjJhJufQ5 0UAYb/n8aB0ejH68FaCncx50dstdRnsR3lvPZ4c2KJFaS+M6vC6unlX3hjgbHUc+gyKY hTdRcaAVdPX9wxW1lDFgQ86LkpBtHUkb68Y1iTvxo0OOgycsu7rcDQJNiDTQMxM2/SoR e1SNBv1KIjWWt9eS3DoLdYA7Z9Kx2kaCB2w4157jiORErakw9QyJ+Wfh1mS45QvwBdH7 Rodw== X-Forwarded-Encrypted: i=1; AJvYcCVbNos6nA/rneBGV2OApd1RfGAw4hG6wW4Z2KCruP19ELH3VKfekF0f6pqjBVZ5jO6B1rr+6FosOFu3Ykw=@vger.kernel.org X-Gm-Message-State: AOJu0YxU2r70lQNRURXBYIpc4dMnCro57Y7WZq1oY8X/d/EYHo9yLJvo 5jNIFVDX1ZaoWEeLZW0O7KYt5ai563e4UN/ZMub8j/Ovd4uaDUrngSFgv4xVCJGplGQ= X-Gm-Gg: AY/fxX5Cd5QnNyGwhEkM15riCodBphF7Rn4xhWEcqOtissnPnmU7BozV2leT4CCoQtH DYrB2P2im16i1oNB+idjtVHppHMGytKiwd3HR9qZPjBEYmAoFfO8kwKb+lHCkVoXY+cJ9414+0u TNqzx4roJU7ZWn43VvyCAdM6JrbB/NY2E+VjLOiAOeV/hoKcLLKdEz6ryCAjFOSr3PbSqOyHfi0 IwTTks+0fBYZiT/Sp/DVQxIgsWdspwzARxByR0hOA1YqNtShpL2o57upQYLVwt69xO/gQ8q8kFq Un5kYIgB9m1sYiv6/SJRGCwPEKHJykjXV2Rev9Xopa9SQMqa6MsnGRNxb58ZrkI/tl5JeonhtsA iuCZjHv0MzeH6N71vBplkfHthts0B5q00jARQU10K8MQM7YRR95BtRQkrTaOyiiWXw27toP+YIw zhGbRLNFgW7AhUX/2mK3Z9MiyjAR/wT0D1+v3keDz5FbyYstZoxYE= X-Google-Smtp-Source: AGHT+IHtEl+Nsh7Sudx4gNAqVHpF5lV6u1SdMvxxbZdekk0b4Vk5JFG+dPcCu/VVDnvDpxsq/g1ikQ== X-Received: by 2002:ac8:6044:0:b0:4f4:c150:7d1c with SMTP id d75a77b69052e-4f4c3ebfe26mr437680291cf.53.1767368550594; Fri, 02 Jan 2026 07:42:30 -0800 (PST) Received: from [172.22.22.28] (c-75-72-117-212.hsd1.mn.comcast.net. [75.72.117.212]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-88d997aeff4sm326161116d6.29.2026.01.02.07.42.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Jan 2026 07:42:30 -0800 (PST) Message-ID: <8241a2a0-62e6-4708-8cf6-58d0a59476ff@riscstar.com> Date: Fri, 2 Jan 2026 09:42:28 -0600 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 v2 3/3] reset: spacemit: fix auxiliary device id To: Yixun Lan Cc: Stephen Boyd , Michael Turquette , Philipp Zabel , Guodong Xu , Inochi Amaoto , linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, linux-riscv@lists.infradead.org, spacemit@lists.linux.dev References: <20251226-06-k1-clk-common-v2-0-28b59418b4df@gentoo.org> <20251226-06-k1-clk-common-v2-3-28b59418b4df@gentoo.org> <546ab443-d0b1-4f21-856c-c74e84511d06@riscstar.com> <20251231020951-GYA2019108@gentoo.org> Content-Language: en-US From: Alex Elder In-Reply-To: <20251231020951-GYA2019108@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/30/25 8:09 PM, Yixun Lan wrote: > Hi Alex, > > On 18:50 Mon 29 Dec , Alex Elder wrote: >> On 12/26/25 12:55 AM, Yixun Lan wrote: >>> Due to the auxiliary register procedure moved to ccu common module, >>> the auxiliary device id need to be adjusted, otherwise reset driver >>> will fail to probe. >>> >>> Signed-off-by: Yixun Lan >>> --- >>> drivers/reset/reset-spacemit.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/reset/reset-spacemit.c b/drivers/reset/reset-spacemit.c >>> index e1272aff28f7..8922e14fa836 100644 >>> --- a/drivers/reset/reset-spacemit.c >>> +++ b/drivers/reset/reset-spacemit.c >>> @@ -278,7 +278,7 @@ static int spacemit_reset_probe(struct auxiliary_device *adev, >>> >>> #define K1_AUX_DEV_ID(_unit) \ >>> { \ >>> - .name = "spacemit_ccu_k1." #_unit "-reset", \ >>> + .name = "spacemit_ccu." _K_RST(_unit), \ >>> .driver_data = (kernel_ulong_t)&k1_ ## _unit ## _reset_data, \ >>> } >> >> The above macro is named K1_AUX_DEV_ID(). Why don't you >> define K3_AUX_DEV_ID(), which could use "k3" in its name? >> > that should also works, the idea of using same macro '_K_RST()' here > is trying to explictly tell users the clock and reset shares same name You mean like "spacemit,k1-syscon-mpmu" is used, and you'd rather name the reset "spacemit.k1-mpmu-reset" because it sort of matches a little better than "spacemit_ccu_k1.mpmu-reset"? Anyway, when K1_AUX_DEV_ID() was defined, it was named that way to suggest a pattern that would mean K3_AUX_DEV_ID() would also be defined. I don't really care where the "k1"/"k3" goes, before or after the period. But I think the "k1" could be encoded explicitly here rather than doing it with _K_RST() (i.e., don't even use a macro). -Alex > >> Anyway, if you go this route I suggest you drop "K1_" from the >> name of this macro. >> > or could further refactor the code, to make K1/K3 drivers share same macro > > anyway I don't want to change this patch, my goal here is tring to fix > reset driver after clock common driver refactored plus the modularization > introduced, it's more proper to leave those refactor work up to Guodong, > since he did a lot adjustment to add reset support for K3 SoC >