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 38D673C499 for ; Wed, 15 Nov 2023 19:40:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="GcU7Rxl4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7CA9C433C7; Wed, 15 Nov 2023 19:40:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1700077249; bh=vr/dtO8NJszeUCyuE3bm4hi3vjdDfzfxedQSLADWtAE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GcU7Rxl4SUQnx36/LnQrVmT4t4Q6C0x8dq8MpR2QABqegYkiPJNvCC/qBYjpljd/R OoOfVx7omA1B5p6fHsohFdxZwtvZYHjSiwAzXIyznO2Lf7y5qV7GCGg2knKztLlmu6 O12yYyM87ogaXXpxpZmnJmQ0rqxC/r5RtnsuHCME= 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.6 167/603] regulator: mt6358: Fail probe on unknown chip ID Date: Wed, 15 Nov 2023 14:11:52 -0500 Message-ID: <20231115191624.755079708@linuxfoundation.org> X-Mailer: git-send-email 2.42.1 In-Reply-To: <20231115191613.097702445@linuxfoundation.org> References: <20231115191613.097702445@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.6-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 65fbd95f1dbb0..4ca8fbf4b3e2e 100644 --- a/drivers/regulator/mt6358-regulator.c +++ b/drivers/regulator/mt6358-regulator.c @@ -688,12 +688,18 @@ static int mt6358_regulator_probe(struct platform_device *pdev) const struct mt6358_regulator_info *mt6358_info; int i, max_regulator, ret; - 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; } ret = mt6358_sync_vcn33_setting(&pdev->dev); -- 2.42.0