From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B8E12C187 for ; Tue, 7 Jan 2025 19:49:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736279364; cv=none; b=aevspAJPHjua/eJyyv2I3zLS+tMizfbJuEGwP6fhTt88dNPYTHgZkf+i5imdJKqY2ooptHIIwnITDT1Ih84567CXkH7K1VZ4opse0+rH7IKn0NHArSqTBXHHrNAy12kpoYhq20mn8wW5QuE2KrXa4LvRnHFx2JbtImyBcJL07mQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736279364; c=relaxed/simple; bh=+t24L6vM/wIbncLuq0v84KTBwY8lronNoXRtV4LZhQ0=; h=Message-ID:Content-Type:MIME-Version:In-Reply-To:References: Subject:From:Cc:To:Date; b=kb3UEMRYOqU3S1VCbru/YE3nbTGy3hQHDtDzjSyCoXrmv8xU+iTIGiTwAu84otvMum9UB2Xdmx1ZHaMMYzRwIhro+CKeAIBXc0/bMqUJw8K7eGFCWGqWHBVTv4Gg/mNeYB1yMb8b6erS4aj/BuYq0YVmW/T30OeSuvoMocK0SNA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Re9VjcoQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Re9VjcoQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1123C4CED6; Tue, 7 Jan 2025 19:49:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736279363; bh=+t24L6vM/wIbncLuq0v84KTBwY8lronNoXRtV4LZhQ0=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=Re9VjcoQtgRY17UzCKN8n7g2uTkqW0y2G/PVnvziRoxEfr45ApiowLtCTGfLItKY0 KOXV5MyKZrrXrUCQzCFhxqo/F0HHyyG453WmUk7wu1FWgHeHMOVGKGzTSXtsKuJeBD Bw3N8nZ6nbhQNTf1hQCtWBwsCaXyHIl4ZaQbgFI0xn+NSfYTG1wVEZJdOElRlxC6ff ez3BF4cEsunWu+1oyg21OI+7Mk56aYwQUs4NfiYNdwkCcOGrV7vxkUxadjCn+wwk2a K6w+dQr/XKNV6hA2ESuJtsOOleXicS1XnHTIdcho1J5oVk0MaD76j0MXIIJgFHZ3Pl XhW/pnecnWPTg== Message-ID: <197c4149efbfa24dee4711923cbddff4.sboyd@kernel.org> Content-Type: text/plain; charset="utf-8" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20241219013507.1939266-1-joe@pf.is.s.u-tokyo.ac.jp> References: <20241219013507.1939266-1-joe@pf.is.s.u-tokyo.ac.jp> Subject: Re: [PATCH v3] spmi: hisi-spmi-controller: manage the OF node reference in device initialization and cleanup From: Stephen Boyd Cc: linux-kernel@vger.kernel.org, krzk@kernel.org, Joe Hattori To: Joe Hattori , mchehab+huawei@kernel.org Date: Tue, 07 Jan 2025 11:49:21 -0800 User-Agent: alot/0.12.dev1+gaa8c22fdeedb Quoting Joe Hattori (2024-12-18 17:35:07) > spmi_controller_probe() increments the refcount of an OF node, but does > not release it. Instead, call of_node_get() in spmi_controller_alloc() > and release it in spmi_ctrl_release() to avoid the reference leak. Also > remove the lines in spmi_pmic_arb_bus_init() and spmi_controller_probe() > where a pdev's of_node is stored after spmi_controller_alloc() is > called, since the node is already set with an incremented refcount in > spmi_controller_alloc(). Those lines do not overwrite the of_node since > they set the same node that the spmi_controller_alloc() does, but are > confusing at the very least. >=20 > This bug was found by an experimental verification tool that I am > developing. >=20 > Fixes: e562cf3aea3e ("spmi: hisi-spmi-controller: move driver from stagin= g") > Signed-off-by: Joe Hattori > --- Applied to spmi-next