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 05D953BB2C for ; Wed, 15 Nov 2023 19:54:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="C9P04NZx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A99C8C433C8; Wed, 15 Nov 2023 19:54:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1700078084; bh=tI75uhQo4QiovYiGUisRCjh8pxlqO+2JmgiKIeS5Gbo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C9P04NZx1/QxgqdGV8JoyQP9fH98h39mY7MVlqGeXjZmjwfGumC5AeI95k+6BB2wQ W3998KKZvLXFvxbjDMWlSgLljNAmvp1EhPt7Yv57JkN2m6cuZEcumlc12APzUxyNd1 2Co1u41gp6b9Fc97A8yDXOks9eoZ00UczcW3N5bw= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, AngeloGioacchino Del Regno , Chen-Yu Tsai , Mark Brown , Sasha Levin Subject: [PATCH 6.1 083/379] regulator: mt6358: Fail probe on unknown chip ID Date: Wed, 15 Nov 2023 14:22:38 -0500 Message-ID: <20231115192650.044330722@linuxfoundation.org> X-Mailer: git-send-email 2.42.1 In-Reply-To: <20231115192645.143643130@linuxfoundation.org> References: <20231115192645.143643130@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chen-Yu Tsai [ Upstream commit 7442edec72bc657e6ce38ae01de9f10e55decfaa ] The MT6358 and MT6366 PMICs, and likely many others from MediaTek, have a chip ID register, making the chip semi-discoverable. The driver currently supports two PMICs and expects to be probed on one or the other. It does not account for incorrect mfd driver entries or device trees. While these should not happen, if they do, it could be catastrophic for the device. The driver should be sure the hardware is what it expects. Make the driver fail to probe if the chip ID presented is not a known one. Suggested-by: AngeloGioacchino Del Regno Fixes: f0e3c6261af1 ("regulator: mt6366: Add support for MT6366 regulator") Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20230913082919.1631287-2-wenst@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- drivers/regulator/mt6358-regulator.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/regulator/mt6358-regulator.c b/drivers/regulator/mt6358-regulator.c index a0441b8086712..de7b5db8f7f2d 100644 --- a/drivers/regulator/mt6358-regulator.c +++ b/drivers/regulator/mt6358-regulator.c @@ -655,12 +655,18 @@ static int mt6358_regulator_probe(struct platform_device *pdev) struct mt6358_regulator_info *mt6358_info; int i, max_regulator; - if (mt6397->chip_id == MT6366_CHIP_ID) { - max_regulator = MT6366_MAX_REGULATOR; - mt6358_info = mt6366_regulators; - } else { + switch (mt6397->chip_id) { + case MT6358_CHIP_ID: max_regulator = MT6358_MAX_REGULATOR; mt6358_info = mt6358_regulators; + break; + case MT6366_CHIP_ID: + max_regulator = MT6366_MAX_REGULATOR; + mt6358_info = mt6366_regulators; + break; + default: + dev_err(&pdev->dev, "unsupported chip ID: %d\n", mt6397->chip_id); + return -EINVAL; } for (i = 0; i < max_regulator; i++) { -- 2.42.0