From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 C609A322B7B for ; Wed, 25 Mar 2026 09:31:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774431118; cv=none; b=ZDZXdkg4KCCdskGH08IashdC6utVvkUVvISt9ZC4fA5cG2ZPgMNdMrYlmVbCCTpv22pnRg2DYXuLWFfXSWv6ql6jdqu74yyV/qFmLG9P4nuG1dt+/x7SrbHQFUNVWlCUfaWlmnkMgsB5JiO+E/WGOVA1LNM/YqpAj1esOTVk+CY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774431118; c=relaxed/simple; bh=w/hbKaEAf5xMVRyhYMppeW+IYPZFDrFUwVxsZEc+SsE=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References: MIME-version:Content-type; b=dLvGt6BGY8NEP0VZcflRyVbp0QAH4tG7VvP/gqgYZ+umG6iUwPK1Svqyhf2BEqGqL7nYhlCO3SWyfcvLTKHVedhsQ1CAgE21pAvvvfZAllymOMMkey55q+7FqUU0zP1WfpNHlVT7mRPvn4x6GaEfAGkMFDxT3qZd7Z+AC0WWR8I= 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=MCNQphXg; arc=none smtp.client-ip=209.85.214.177 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="MCNQphXg" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2b0603ee486so15652115ad.0 for ; Wed, 25 Mar 2026 02:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774431117; x=1775035917; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:message-id:date :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=TF/+cxtFW65/t3CsODFg6Eg+Msha9EyFtJo/8aQf58o=; b=MCNQphXgbc8EpPzAuqYR8djm6txUWJstcMPwRNfsTZk6b22vUePuvsml+PJUK3mm76 Lkow+Z82dj75WBS7/AA5c8i+Tr5QWwCvO3rRAZAhYLZ983FdJi/h8SQV9O7JB+SaQcAg CwkiIgU1OWgGBovJCAhscMIfL/QNgLZ+Q5VAArKhAMVlaRHXUjSBtNSsQKFEMUymHf8y kDYmx8nd7ephwuINvgjtBDyMaSYzZDpS/wIJOB7MzwDhWQzFKBHjCjduwobnkanxLXs5 aI1q19ZknrG3abF/C91ofTS62I+Q4OIWQZQ5XoOX6yO6ya5BppJUWdkzGTnTptZzBtTO rOPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774431117; x=1775035917; h=content-transfer-encoding:mime-version:references:message-id:date :in-reply-to:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=TF/+cxtFW65/t3CsODFg6Eg+Msha9EyFtJo/8aQf58o=; b=Ca7SZHdMmbO6sqp9an629s4ui4YaohYm+NDAFkDMD62FjIHYGA5tCjwy1UCh2TVW8Q Qqq1bniGkxmZJl9Wsim9BwHXJ0CviTwImg4ElXBYeofAIuxJIjWPfwUKuw0rgaivoJIT v8QidR1pYm+iGN/1DeXmC0R76tqqwK8jHsHXy25qGti8HAvcsRJ/x4zcCSYFOJz5bGzf 9smP6HqsEqRjmjY3CeJGRpgPQHWUVYMltDKYeefYKdROAezuj0UvQCZmZCXoB3o+ipEf eFogpWPhMOxI/UJNMc8CG+IvQ3wTUOkYXxoK2NJRPX1ZYRrbI/Ysf/ZJYle8+K3hHz8o Ju4g== X-Gm-Message-State: AOJu0YxAzQ/F2mC4ElYHw3VaAY+jL3Spe4qZSCuNkfwHpNou1XXFuLxs fKM4z2fu71mmwBDaxJ9veAO9XRCwzBEaAtdpO9TNITNOb64UUe/1zfkH X-Gm-Gg: ATEYQzy3k/7z/S0OEIsPzU4heRmMiPb/LZQSwWWWO0PLNbd81Uq8Cg4cpaY3aU7zMKO v3koxE9KydgCjEBWdyktzKP3chjzbJH1MU4POihqW3sl5HhrtOMZaTZ8PKCOmOE+cy2zUjhXkpN D3IdsICqMzvBbVgKWnDouIa7M3CQY7O8awdnFJa+tEXPsuR3Ty5pHoIqFzSTfGVLwwO2WYG0U76 HKdSu46eY/z1TKsEUilgaXFBlgZXg9iuYNnog2yejBQWIzZdNiOtHaJSBJEEOPOk1ws4tSeV2gA uWEEAZxoCCUo/XXOF6C/UR+muJe5/UQEg4YWe455wamKyFIJdz02kECtwOKR7JvA0+ImZa0coc7 jz/oEYD471ZCt7hl/BfQIMAG9eFsRVanBC/Rfjkygl6h/QkYKebdUKNyW85wA1f5o0c6Q7Rn/AH n0L7RyKd27wFRFs4iXEX9LatUarayQ+0i9 X-Received: by 2002:a17:903:37cf:b0:2b0:41bf:ca83 with SMTP id d9443c01a7336-2b0b0a48b14mr30087295ad.23.1774431117028; Wed, 25 Mar 2026 02:31:57 -0700 (PDT) Received: from pve-server ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b0b0129905sm25660755ad.27.2026.03.25.02.31.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Mar 2026 02:31:56 -0700 (PDT) From: Ritesh Harjani (IBM) To: "Christophe Leroy (CS GROUP)" , Venkat Rao Bagalkote , arnd@arndb.de, gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, nathan@kernel.org, nsc@kernel.org, ojeda@kernel.org, masahiroy@kernel.org, linux@weissschuh.net, tamird@kernel.org, rostedt@goodmis.org, ihor.solodrai@linux.dev, maddy@linux.ibm.com, peterz@infradead.org Subject: Re: [PATCH v2] char: nvram: Remove unused nvram_mutex to fix -Wunused-variable warning In-Reply-To: Date: Wed, 25 Mar 2026 14:34:04 +0530 Message-ID: <7br0nuuz.ritesh.list@gmail.com> References: <20260323073220.25798-1-venkat88@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit "Christophe Leroy (CS GROUP)" writes: > Le 23/03/2026 à 08:32, Venkat Rao Bagalkote a écrit : >> v2: >> - Added missing Suggested-by tag from Ritesh Harjani (IBM) >> > > Patch history must go _after_ the --- below, otherwise it will appear in > the commit message when applied, which is pointless. > >> drivers/char/nvram.c defines a static mutex 'nvram_mutex' which is never >> used. This results in a compiler warning on linux-next builds: > > It is probably not only linux-next builds, I think the problem exists > since 20e07af71f34 ("powerpc: Adopt nvram module for PPC64") > >> >> warning: 'nvram_mutex' defined but not used [-Wunused-variable] >> >> Remove the unused definition to avoid the warning. > > It is not what you are doing. > > You are just hiding the probleme by saying 'maybe it is used, maybe it > is not used, I don't know I don't care". Venkat, do cares about this warning, and hence he sent the patch in trying to fix it ;) I think, I missed seeing the upper #ifdef block of PPC, and hence suggested him to use __maybe_unused, instead of complicating it further with... #if defined(CONFIG_PPC32) || defined(CONFIG_X86) || defined(CONFIG_M68K), > Please properly fix the problem instead. > I agree, make sense. > I think the fix is probably to remove the #ifdef CONFIG_PPC32 around > IOC_NVRAM_SYNC. > If you think it is important to return -ENOTTY on CONFIG_PPC64, just add: > That make sense and I should have thought of that. However, I looked at the suggestions from Arnd, and I too agree that all underneath function operations already do their own locking, so I agree that we could just kill this nvram_mutex lock itself. -ritesh