diff mbox series

cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriately

Message ID 20240828131915.3198081-1-nm@ti.com (mailing list archive)
State New
Delegated to: viresh kumar
Headers show
Series cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriately | expand

Commit Message

Nishanth Menon Aug. 28, 2024, 1:19 p.m. UTC
Commit b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx
and omap36xx") introduced special handling for OMAP3 class devices
where syscon node may not be present. However, this also creates a bug
where the syscon node is present, however the offset used to read
is beyond the syscon defined range.

Fix this by providing a quirk option that is populated when such
special handling is required. This allows proper failure for all other
platforms when the syscon node and efuse offsets are mismatched.

Fixes: b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx and omap36xx")
Signed-off-by: Nishanth Menon <nm@ti.com>
---

NOTE: this combined with https://lore.kernel.org/r/20240828121008.3066002-1-nm@ti.com
has created a bunch of un-intended bugs on other TI SoCs such
as seen in https://lore.kernel.org/all/20240826-opp-v3-1-0934f8309e13@ti.com/
https://lore.kernel.org/all/20240827131342.6wrielete3yeoinl@bryanbrattlof.com/
etc.

 drivers/cpufreq/ti-cpufreq.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

Comments

Dhruva Gole Aug. 30, 2024, 10:04 a.m. UTC | #1
Hi,

On Aug 28, 2024 at 08:19:15 -0500, Nishanth Menon wrote:
> Commit b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx
> and omap36xx") introduced special handling for OMAP3 class devices
> where syscon node may not be present. However, this also creates a bug
> where the syscon node is present, however the offset used to read
> is beyond the syscon defined range.
> 
> Fix this by providing a quirk option that is populated when such
> special handling is required. This allows proper failure for all other
> platforms when the syscon node and efuse offsets are mismatched.
> 
> Fixes: b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx and omap36xx")
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> 
> NOTE: this combined with https://lore.kernel.org/r/20240828121008.3066002-1-nm@ti.com
> has created a bunch of un-intended bugs on other TI SoCs such
> as seen in https://lore.kernel.org/all/20240826-opp-v3-1-0934f8309e13@ti.com/
> https://lore.kernel.org/all/20240827131342.6wrielete3yeoinl@bryanbrattlof.com/
> etc.

I have been able to verify that this doesn't cause any regressions on
AM62x cpufreq, logs [0]. I also applied the other syscon patch mentioned
above. So,

Tested-by: Dhruva Gole <d-gole@ti.com>

[0] https://gist.github.com/DhruvaG2000/153b5511889180ee54703603428fb77e
Kevin Hilman Aug. 30, 2024, 5:59 p.m. UTC | #2
Nishanth Menon <nm@ti.com> writes:

> Commit b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx
> and omap36xx") introduced special handling for OMAP3 class devices
> where syscon node may not be present. However, this also creates a bug
> where the syscon node is present, however the offset used to read
> is beyond the syscon defined range.
>
> Fix this by providing a quirk option that is populated when such
> special handling is required. This allows proper failure for all other
> platforms when the syscon node and efuse offsets are mismatched.
>
> Fixes: b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx and omap36xx")
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>
> NOTE: this combined with https://lore.kernel.org/r/20240828121008.3066002-1-nm@ti.com
> has created a bunch of un-intended bugs on other TI SoCs such
> as seen in https://lore.kernel.org/all/20240826-opp-v3-1-0934f8309e13@ti.com/
> https://lore.kernel.org/all/20240827131342.6wrielete3yeoinl@bryanbrattlof.com/
> etc.

Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Viresh Kumar Sept. 3, 2024, 9:02 a.m. UTC | #3
On 28-08-24, 08:19, Nishanth Menon wrote:
> Commit b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx
> and omap36xx") introduced special handling for OMAP3 class devices
> where syscon node may not be present. However, this also creates a bug
> where the syscon node is present, however the offset used to read
> is beyond the syscon defined range.
> 
> Fix this by providing a quirk option that is populated when such
> special handling is required. This allows proper failure for all other
> platforms when the syscon node and efuse offsets are mismatched.
> 
> Fixes: b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx and omap36xx")
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> 

Applied. Thanks.
diff mbox series

Patch

diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 220fff7a302e..804329e81eb8 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -90,6 +90,9 @@  struct ti_cpufreq_soc_data {
 	unsigned long efuse_shift;
 	unsigned long rev_offset;
 	bool multi_regulator;
+/* Backward compatibility hack: Might have missing syscon */
+#define TI_QUIRK_SYSCON_MAY_BE_MISSING	0x1
+	u8 quirks;
 };
 
 struct ti_cpufreq_data {
@@ -254,6 +257,7 @@  static struct ti_cpufreq_soc_data omap34xx_soc_data = {
 	.efuse_mask = BIT(3),
 	.rev_offset = OMAP3_CONTROL_IDCODE - OMAP3_SYSCON_BASE,
 	.multi_regulator = false,
+	.quirks = TI_QUIRK_SYSCON_MAY_BE_MISSING,
 };
 
 /*
@@ -281,6 +285,7 @@  static struct ti_cpufreq_soc_data omap36xx_soc_data = {
 	.efuse_mask = BIT(9),
 	.rev_offset = OMAP3_CONTROL_IDCODE - OMAP3_SYSCON_BASE,
 	.multi_regulator = true,
+	.quirks = TI_QUIRK_SYSCON_MAY_BE_MISSING,
 };
 
 /*
@@ -295,6 +300,7 @@  static struct ti_cpufreq_soc_data am3517_soc_data = {
 	.efuse_mask = 0,
 	.rev_offset = OMAP3_CONTROL_IDCODE - OMAP3_SYSCON_BASE,
 	.multi_regulator = false,
+	.quirks = TI_QUIRK_SYSCON_MAY_BE_MISSING,
 };
 
 static struct ti_cpufreq_soc_data am625_soc_data = {
@@ -340,7 +346,7 @@  static int ti_cpufreq_get_efuse(struct ti_cpufreq_data *opp_data,
 
 	ret = regmap_read(opp_data->syscon, opp_data->soc_data->efuse_offset,
 			  &efuse);
-	if (ret == -EIO) {
+	if (opp_data->soc_data->quirks & TI_QUIRK_SYSCON_MAY_BE_MISSING && ret == -EIO) {
 		/* not a syscon register! */
 		void __iomem *regs = ioremap(OMAP3_SYSCON_BASE +
 				opp_data->soc_data->efuse_offset, 4);
@@ -381,7 +387,7 @@  static int ti_cpufreq_get_rev(struct ti_cpufreq_data *opp_data,
 
 	ret = regmap_read(opp_data->syscon, opp_data->soc_data->rev_offset,
 			  &revision);
-	if (ret == -EIO) {
+	if (opp_data->soc_data->quirks & TI_QUIRK_SYSCON_MAY_BE_MISSING && ret == -EIO) {
 		/* not a syscon register! */
 		void __iomem *regs = ioremap(OMAP3_SYSCON_BASE +
 				opp_data->soc_data->rev_offset, 4);