From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 0A7C42ED17C for ; Tue, 25 Nov 2025 23:34:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764113656; cv=none; b=RRUBpSMyAFKNZdAvaPu7XxbbiRxdC90b+vdCuqQFyn3afAiLZI7cM19ZE5w2DeAZbsR/cJ0xoOfwODqcVED9h/mkwlHcJjprDThFFfAOnaE95Qy0pPVu+wxST9QqpqVQeHFZp0cMxxVqGapCjhvHH00O8siJyi2Xw+IJM5K2KNA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764113656; c=relaxed/simple; bh=7OIcc9KkXH6wW5HnKG3kaGMWstSD64sRgn5IR3BBUQE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KEKiKyHBmfxv2aIFIY//1rH/uRpNFJMzGFStNsDm0L7UYKOfKJ2AVds75odF23ei4aR7UUc0xy5kLmJUdgiUqOSCoZMouWDFgUhPOc28ikZlVtcDB61C4O3t0betocrNlHP0O//auMSF12yrwJ9zSFZwTdQDkeV4YEA+Ym7ubf0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=MCFfcoX4; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MCFfcoX4" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-47789cd2083so36489065e9.2 for ; Tue, 25 Nov 2025 15:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764113653; x=1764718453; 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=YSgFECtP1z+NfavQTbIkfavnGHKDphcmbRff6uSNyR4=; b=MCFfcoX41b50PjXU/MyH+EWNKtFgNMeprKBxznEuXO+b06vqRwB7NCgd7Su3EFleFM iEnnUFeIVUKzup0K7/tPOF0v2etOOHoWBOAGAyiMmpJadFe2TdtlMkXeXbpGQZBSEXUV wFjN1eejLYzi7tPbkSYf6QC+/YBxf2EX6Wmu4qtkPdF//M0jrHAjHQ7eMAOYcXFdugHZ 84IKz/sNdoaQceg1Zcu1E9L4AqSrQAuxqpFwTppJrk7f0nM9nVOMUoVIAIilXjwi3Ph7 kQGWoDQt8+WRqWat5vZnWeAqnkVnZfJYht3XLZJd2NAcrCGRoTU5arrBzz0X34u+YQy2 M4NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764113653; x=1764718453; 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=YSgFECtP1z+NfavQTbIkfavnGHKDphcmbRff6uSNyR4=; b=uTB39HUXsNLgUz0V/9B8/9x0mvn0eMM+0SnK+gsYFKwl7l9SFEuYDPMunQc9AfwNpH 1dcNO+0plBFizPXJ+b/8WRfeB09NkMEQDE5ME8JYVzyWAoYKamJCJ0ulmT+qv5V3zDeh OKcZIoo2Tg9BeOLP/SSdpvaGGl3Hn28xYTY9DmPxIn0Sno1fFnGQlIZD6kY/OxhdIfEl iytg7De4Uo40EtyziIM/vXUiRurKmsDFaz5v01S8CXR9Ha9VS0DcN5axVBT0iGuyCY5D 8lWNcvcy6r5sHn612lakAaCfX+WaAb+blOVtzyOXaL4u81j2O1kteGSDEPl6wXZnPPYo DrjA== X-Forwarded-Encrypted: i=1; AJvYcCXev1NE8uA4WlUeeTt190Uve4dLQH/WJQq5jTCvzfBCOZOC59ERCQuBa+5dVYIsxVTeMjnruL8UcevDUFg=@vger.kernel.org X-Gm-Message-State: AOJu0Yyl8N+o32ClvwY8WzOqx8GEpMT4HzOs6LUJxdqecZGYutC35K4M M9xTyk6hbmM7TGQlA3NIyeINsFO9whUf0QicydlK/Hen/zck7C4t+PJF X-Gm-Gg: ASbGncvc7uW0HCo8uyqjHG6hZ58pz2J3cbX/zwE+GGrLHtL2gHmrtchP12NEAroj4+6 bY6JzQZX4Clvgpxs7ZXuPChGWSr1BfYUqXZz9IvT+lMlfC+NEIMsnYkid4FIsnI+aUxa7PvKV7u byVHrSRmQ3wzYmQ1/W5XvwTzFiJC5u2VyANCfVCIPrTXwSKsvyjEIJ5qv1FETrzNeSr8Js6KJ9s UGFCKHlRbWh6VSp2L371YX/IdOUAAag2GTzsxyYajenba2iDS5hLOMyTbArxFnUk/9NCQBgovWv 6EGUcZc+XPFMSscUaSkXFaDzZafW3BSDefxAiAPoIT4QaDextImmVNzVpFx+tq0b7nZt7ednfxC NA1eX9toiCKVqXZDmpA6B9gTPKMJuuACrbOYvS+tpMkHzEEr8aQkQJB6gcQNP3xeAtIp3tUiw7G 0frxNiceiphRlsmIYlpMQN5zP7J92MR9jRtAzHlDBQ9A== X-Google-Smtp-Source: AGHT+IFalyeW7faMHDifKV64koi9lzILMgomHzb1dC1jupNeqdx4t6uHO6adv/AIDeDahL7H73btnA== X-Received: by 2002:a05:600c:4443:b0:477:af74:ed64 with SMTP id 5b1f17b1804b1-477c114f00amr174145245e9.27.1764113652924; Tue, 25 Nov 2025 15:34:12 -0800 (PST) Received: from [192.168.1.129] ([82.79.237.20]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4790addeeaasm12850205e9.7.2025.11.25.15.34.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Nov 2025 15:34:12 -0800 (PST) Message-ID: <9ce8bcf1-7a62-44ce-81e3-f1c51f8be9b0@gmail.com> Date: Wed, 26 Nov 2025 01:34:10 +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 v5 2/6] reset: imx8mp-audiomix: Replace mask with bit index To: Philipp Zabel , Frank Li Cc: Krzysztof Kozlowski , Conor Dooley , Shawn Guo , Fabio Estevam , Daniel Baluta , Shengjiu Wang , devicetree@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Pengutronix Kernel Team References: <20251114133738.1762-1-laurentiumihalcea111@gmail.com> <20251114133738.1762-3-laurentiumihalcea111@gmail.com> <6be8a682-6c72-45c8-be0e-880ab66045ff@gmail.com> <4a022153-009c-44fd-8c4b-39819ae69390@gmail.com> <9f07e541fc000d9065c1ff1716f1edc4c2278c8d.camel@pengutronix.de> Content-Language: en-US From: Laurentiu Mihalcea In-Reply-To: <9f07e541fc000d9065c1ff1716f1edc4c2278c8d.camel@pengutronix.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/25/2025 12:40 PM, Philipp Zabel wrote: > On Di, 2025-11-25 at 01:59 -0800, Laurentiu Mihalcea wrote: >> On 11/24/2025 7:41 AM, Frank Li wrote: >>> On Mon, Nov 24, 2025 at 01:28:32AM -0800, Laurentiu Mihalcea wrote: >>>> On 11/21/2025 7:38 AM, Frank Li wrote: >>>>> On Fri, Nov 14, 2025 at 05:37:34AM -0800, Laurentiu Mihalcea wrote: >>>>>> From: Laurentiu Mihalcea >>>>>> >>>>>> Replace the reset map mask with the bit index to make it clear that all >>>>>> reset lines are managed by exactly 1 bit. >>>>> I don't think there are benefit because I met some periphal need a magic >>>>> number to reset. > Toggling multiple bits in unison is different from having to write a > magic number to a register field. The driver currently supports > neither. That is why I suggested to change from mask to bit. > >>>> Please provide more information. What SoC? Which peripherals? What block control? >>>> >>> I can't reminder exact one. I grep some code >>> >>> [IMX8MP_MEDIABLK_PD_LCDIF_1] = { >>> .name = "mediablk-lcdif-1", >>> .clk_names = (const char *[]){ "disp1", "apb", "axi", }, >>> .num_clks = 3, >>> .gpc_name = "lcdif1", >>> .rst_mask = BIT(4) | BIT(5) | BIT(23), >>> .clk_mask = BIT(4) | BIT(5) | BIT(23), > According to the reference manual, these are three separate software > resets for three separate clocks: lcdif_pixel_clk, lcdif_apb_clk, and > lcdif_axi_clk. > >>> .path_names = (const char *[]){"lcdif-rd", "lcdif-wr"}, >>> .num_paths = 2, >>> }, >>> >>> mask is more extenable and easily support more hardware in future. > If such hardware appears in the future, it will be easy to adapt the > driver. Usually we don't prematurely add complexity for possible future > hardware. > >>> Change to bit number have not big benefit. > It improves readability as it makes immediately clear from the code > that all resets correspond to a single bit. > >> sure, I'm fine with the mask-based approach. The big idea here is to make this driver >> usable in as many scenarios as possible. >> >> Philipp, please let me know if you're okay with the proposal. Will also have to tweak >> one of the subsequent patches since, so far, we've been operating under the assumption >> that reset lines are 1 bit. > Given that the current code is already using mask, and if you think it > is likely that there will be need for reset controls that require > toggling multiple bits with a single write, I'm fine with keeping the > mask. ACK. Unfortunately, I don't have an use-case for this driver in which we'd want to manage multiple underlying reset lines as a single one like in Frank's example. I'm also assuming Frank doesn't have one either based on his previous comment. Despite this, however, the previous version of the driver was already able to handle this use-case. The single-bit reset restriction was introduced by this series. Therefore, I suggest we reduce the number of changes and revert to the old behavior. This way, we'll avoid reverting the patches if someone does ever come up with such an use-case. I'd say the driver is simple enough that the code readability will not be severely impacted. Either way, I think we'd be fine with any of the two approaches in the end. > > regards > Philipp