Farewell Armada 375 Z1 support
Subsystems (6)
cover Farewell Armada 375 Z1 support
Hi all,
As we recently discussed [1], the Armada 375 Z1 stepping is no longer supported.
Once the 25 MHz reference clock patches are merged, watchdog and clocksource will stop working properly [2]. Also, the ethernet driver for Armada 375 SoC (mvpp2) never supported the Z1 stepping.
These two patches remove the thermal quirk needed for Z1, which currently is the only piece that explicitly mentions Z1.
[1] http://www.spinics.net/lists/arm-kernel/msg374443.html
[2] http://www.spinics.net/lists/arm-kernel/msg371524.html
Ezequiel Garcia (2):
thermal: armada: Remove support for A375-Z1 SoC
ARM: mvebu: Remove thermal quirk for Z1 SoC
.../devicetree/bindings/thermal/armada-thermal.txt | 8 --- arch/arm/mach-mvebu/board-v7.c | 66 +--------------------- drivers/thermal/armada_thermal.c | 20 ------- 3 files changed, 1 insertion(+), 93 deletions(-)
Signature · 1 line
2.1.0
PATCH 1/2 thermal: armada: Remove support for A375-Z1 SoC
The Armada 375 Z1 SoC revision is no longer supported. This commit removes the quirk needed for the thermal sensor.
--- .../devicetree/bindings/thermal/armada-thermal.txt | 8 -------- drivers/thermal/armada_thermal.c | 20 -------------------- 2 files changed, 28 deletions(-)
Documentation/devicetree/bindings/thermal/armada-thermal.txt +0 -8
@@ -5,17 +5,9 @@ Required properties: - compatible: Should be set to one of the following: marvell,armada370-thermal marvell,armada375-thermal - marvell,armada375-z1-thermal marvell,armada380-thermal marvell,armadaxp-thermal - Note: As the name suggests, "marvell,armada375-z1-thermal" - applies for the SoC Z1 stepping only. On such stepping - some quirks need to be done and the register offset differs - from the one in the A0 stepping. - The operating system may auto-detect the SoC stepping and - update the compatible and register offsets at runtime. - - reg: Device's register space. Two entries are expected, see the examples below. The first one is required for the sensor register;
drivers/thermal/armada_thermal.c +0 -20
@@ -35,10 +35,6 @@#define PMU_TDC0_OTF_CAL_MASK (0x1 << 30)#define PMU_TDC0_START_CAL_MASK (0x1 << 25) -#define A375_Z1_CAL_RESET_LSB 0x8011e214 -#define A375_Z1_CAL_RESET_MSB 0x30a88019 -#define A375_Z1_WORKAROUND_BIT BIT(9) -#define A375_UNIT_CONTROL_SHIFT 27#define A375_UNIT_CONTROL_MASK 0x7#define A375_READOUT_INVERT BIT(15)
@@ -124,24 +120,12 @@ static void armada375_init_sensor(struct platform_device *pdev, struct armada_thermal_priv *priv) {unsigned long reg; -bool quirk_needed = - !!of_device_is_compatible (pdev->dev.of_node, -"marvell,armada375-z1-thermal" ); - -if (quirk_needed) { -/* Ensure these registers have the default (reset) values */ -writel (A375_Z1_CAL_RESET_LSB , priv->control); -writel (A375_Z1_CAL_RESET_MSB , priv->control +0x4 ); - } reg =readl (priv->control +4 ); reg &= ~(A375_UNIT_CONTROL_MASK <<A375_UNIT_CONTROL_SHIFT ); reg &= ~A375_READOUT_INVERT ; reg &= ~A375_HW_RESETn; -if (quirk_needed) - reg |=A375_Z1_WORKAROUND_BIT ; -writel (reg, priv->control +4 );mdelay (20 );
@@ -260,10 +244,6 @@ static const struct of_device_id armada_thermal_id_table[] = { .data = &armada375_data, }, { - .compatible = "marvell,armada375-z1-thermal", - .data = &armada375_data, - }, - { .compatible = "marvell,armada380-thermal", .data = &armada380_data, },
Signature · 1 line
2.1.0
PATCH 1/2 thermal: armada: Remove support for A375-Z1 SoC
Ezequiel,
Quoted 21 lines · Ezequiel Garcia
The Armada 375 Z1 SoC revision is no longer supported. This commit removes the quirk needed for the thermal sensor.
Signed-off-by Ezequiel Garcia <[email protected]>--- .../devicetree/bindings/thermal/armada-thermal.txt | 8 -------- drivers/thermal/armada_thermal.c | 20 -------------------- 2 files changed, 28 deletions(-)Documentation/devicetree/bindings/thermal/armada-thermal.txt +0
-1@@ -5,17 +5,9 @@ Required properties: - compatible: Should be set to one of the following: marvell,armada370-thermal marvell,armada375-thermal - marvell,armada375-z1-thermal marvell,armada380-thermal marvell,armadaxp-thermal
Documentation/devicetree/bindings/thermal/armada-thermal.txt Required properties: · line 13
Quoted 10 lines
Documentation/devicetree/bindings/thermal/armada-thermal.txt +0
-7- Note: As the name suggests, "marvell,armada375-z1-thermal" - applies for the SoC Z1 stepping only. On such stepping - some quirks need to be done and the register offset differs - from the one in the A0 stepping. - The operating system may auto-detect the SoC stepping and - update the compatible and register offsets at runtime. - - reg: Device's register space. Two entries are expected, see the examples below. The first one is required for the sensor register;
I've no problem with removing support for the z1 stepping from the kernel. However, I don't think we should erase it from binding docs. I'm not sure what the DT maintainers think is the appropriate action here, but I'm thinking we could add a 'Deprecated' section at the end of the doc and move these hunks there. With a little rewording of course.
I'm primarily concerned about users with older dtbs looking to upgrade, "Hey, wtf is marvell,armada375-z1-thermal? I looked in the binding docs and there's nothing there, do I replace it with marvell,armada375-thermal?"
thx,
Jason.
PATCH 1/2 thermal: armada: Remove support for A375-Z1 SoC
Quoted 41 lines · Jason Cooper
Ezequiel,
Quoted 21 lines · Ezequiel Garcia
The Armada 375 Z1 SoC revision is no longer supported. This commit removes the quirk needed for the thermal sensor.
Signed-off-by Ezequiel Garcia <[email protected]>--- .../devicetree/bindings/thermal/armada-thermal.txt | 8 -------- drivers/thermal/armada_thermal.c | 20 -------------------- 2 files changed, 28 deletions(-)Documentation/devicetree/bindings/thermal/armada-thermal.txt +0
-1@@ -5,17 +5,9 @@ Required properties: - compatible: Should be set to one of the following: marvell,armada370-thermal marvell,armada375-thermal - marvell,armada375-z1-thermal marvell,armada380-thermal marvell,armadaxp-thermalDocumentation/devicetree/bindings/thermal/armada-thermal.txt Required properties: · line 13
Quoted 10 lines
Documentation/devicetree/bindings/thermal/armada-thermal.txt +0
-7- Note: As the name suggests, "marvell,armada375-z1-thermal" - applies for the SoC Z1 stepping only. On such stepping - some quirks need to be done and the register offset differs - from the one in the A0 stepping. - The operating system may auto-detect the SoC stepping and - update the compatible and register offsets at runtime. - - reg: Device's register space. Two entries are expected, see the examples below. The first one is required for the sensor register;I've no problem with removing support for the z1 stepping from the kernel. However, I don't think we should erase it from binding docs. I'm not sure what the DT maintainers think is the appropriate action here, but I'm thinking we could add a 'Deprecated' section at the end of the doc and move these hunks there. With a little rewording of course.
Quoted 4 lines
I'm primarily concerned about users with older dtbs looking to upgrade, "Hey, wtf is marvell,armada375-z1-thermal? I looked in the binding docs and there's nothing there, do I replace it with marvell,armada375-thermal?"
We can do that if you think it's really useful. However, I think we've designed this so *nobody* would actually have to put the z1 compatible string. The mvebu quirk (tries) to auto-detect it from the revision register and hot fix the compatible string.
Moreover, I'm not at all sure *anyone* would have a Z1 board except early developers like us. Am I being too naive here?
Signature · 11 lines
Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141107/72590425/attachment.sig>
PATCH 1/2 thermal: armada: Remove support for A375-Z1 SoC
Ezequiel,
+ Mark, Grant (sorry, thought you were Cc'd on the original patch)
Quoted 47 lines · Ezequiel Garcia
Quoted 41 lines · Jason Cooper
Ezequiel,
Quoted 21 lines · Ezequiel Garcia
The Armada 375 Z1 SoC revision is no longer supported. This commit removes the quirk needed for the thermal sensor.
Signed-off-by Ezequiel Garcia <[email protected]>--- .../devicetree/bindings/thermal/armada-thermal.txt | 8 -------- drivers/thermal/armada_thermal.c | 20 -------------------- 2 files changed, 28 deletions(-)Documentation/devicetree/bindings/thermal/armada-thermal.txt +0
-1@@ -5,17 +5,9 @@ Required properties: - compatible: Should be set to one of the following: marvell,armada370-thermal marvell,armada375-thermal - marvell,armada375-z1-thermal marvell,armada380-thermal marvell,armadaxp-thermalDocumentation/devicetree/bindings/thermal/armada-thermal.txt Required properties: · line 13
Quoted 10 lines
Documentation/devicetree/bindings/thermal/armada-thermal.txt +0
-7- Note: As the name suggests, "marvell,armada375-z1-thermal" - applies for the SoC Z1 stepping only. On such stepping - some quirks need to be done and the register offset differs - from the one in the A0 stepping. - The operating system may auto-detect the SoC stepping and - update the compatible and register offsets at runtime. - - reg: Device's register space. Two entries are expected, see the examples below. The first one is required for the sensor register;I've no problem with removing support for the z1 stepping from the kernel. However, I don't think we should erase it from binding docs. I'm not sure what the DT maintainers think is the appropriate action here, but I'm thinking we could add a 'Deprecated' section at the end of the doc and move these hunks there. With a little rewording of course.
Quoted 4 lines
I'm primarily concerned about users with older dtbs looking to upgrade, "Hey, wtf is marvell,armada375-z1-thermal? I looked in the binding docs and there's nothing there, do I replace it with marvell,armada375-thermal?"
Quoted 7 lines
We can do that if you think it's really useful. However, I think we've designed this so *nobody* would actually have to put the z1 compatible string. The mvebu quirk (tries) to auto-detect it from the revision register and hot fix the compatible string.
Moreover, I'm not at all sure *anyone* would have a Z1 board except early developers like us. Am I being too naive here?
I'm primarily concerned about dtbs in the wild which have that compatible string. But as you mention, and a quick grep proves, this compatible string was never in a dts{i} file. At least not in the kernel tree.
It's not a rush, so I'd like to hear from Mark/Grant what they prefer for this sort of situation. It'll be in the git history either way, but not everyone goes there when the current docs don't mention something. :)
thx,
Jason.
PATCH 1/2 thermal: armada: Remove support for A375-Z1 SoC
In reply to Ezequiel GarciaDear Ezequiel Garcia,
Quoted 4 lines · Ezequiel Garcia
We can do that if you think it's really useful. However, I think we've designed this so *nobody* would actually have to put the z1 compatible string. The mvebu quirk (tries) to auto-detect it from the revision register and hot fix the compatible string.
Correct.
Quoted 2 lines
Moreover, I'm not at all sure *anyone* would have a Z1 board except early developers like us. Am I being too naive here?
I confirm: those early revisions have only been provided to a very small selection of persons, mainly within Marvell, and only a few external partners which are all well aware of the early status of such SoC revisions.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/2 thermal: armada: Remove support for A375-Z1 SoC
In reply to Ezequiel GarciaQuoted 8 lines · Ezequiel Garcia
The Armada 375 Z1 SoC revision is no longer supported. This commit removes the quirk needed for the thermal sensor.
Signed-off-by Ezequiel Garcia <[email protected]>--- .../devicetree/bindings/thermal/armada-thermal.txt | 8 -------- drivers/thermal/armada_thermal.c | 20 -------------------- 2 files changed, 28 deletions(-)
As Thomas and Ezequiel rightfully mentioned, the compatible string below has never been in a dts file. Our arch code detected the Z1, and changed the compatible on the fly. As a result, there shouldn't be any dtbs in the wild with this compatible string. If there are, it will be held by the few developers (Marvell, partners) that know what they are doing.
thx,
Jason.
Quoted 76 lines
Documentation/devicetree/bindings/thermal/armada-thermal.txt +0
-8@@ -5,17 +5,9 @@ Required properties: - compatible: Should be set to one of the following: marvell,armada370-thermal marvell,armada375-thermal - marvell,armada375-z1-thermal marvell,armada380-thermal marvell,armadaxp-thermal - Note: As the name suggests, "marvell,armada375-z1-thermal" - applies for the SoC Z1 stepping only. On such stepping - some quirks need to be done and the register offset differs - from the one in the A0 stepping. - The operating system may auto-detect the SoC stepping and - update the compatible and register offsets at runtime. - - reg: Device's register space. Two entries are expected, see the examples below. The first one is required for the sensor register;drivers/thermal/armada_thermal.c +0
-20@@ -35,10 +35,6 @@#define PMU_TDC0_OTF_CAL_MASK (0x1 << 30)#define PMU_TDC0_START_CAL_MASK (0x1 << 25) -#define A375_Z1_CAL_RESET_LSB 0x8011e214 -#define A375_Z1_CAL_RESET_MSB 0x30a88019 -#define A375_Z1_WORKAROUND_BIT BIT(9) -#define A375_UNIT_CONTROL_SHIFT 27#define A375_UNIT_CONTROL_MASK 0x7#define A375_READOUT_INVERT BIT(15)@@ -124,24 +120,12 @@ static void armada375_init_sensor(struct platform_device *pdev, struct armada_thermal_priv *priv) {unsigned long reg; -bool quirk_needed = - !!of_device_is_compatible (pdev->dev.of_node, -"marvell,armada375-z1-thermal" ); - -if (quirk_needed) { -/* Ensure these registers have the default (reset) values */ -writel (A375_Z1_CAL_RESET_LSB , priv->control); -writel (A375_Z1_CAL_RESET_MSB , priv->control +0x4 ); - } reg =readl (priv->control +4 ); reg &= ~(A375_UNIT_CONTROL_MASK <<A375_UNIT_CONTROL_SHIFT ); reg &= ~A375_READOUT_INVERT ; reg &= ~A375_HW_RESETn; -if (quirk_needed) - reg |=A375_Z1_WORKAROUND_BIT ; -writel (reg, priv->control +4 );mdelay (20 );@@ -260,10 +244,6 @@ static const struct of_device_id armada_thermal_id_table[] = { .data = &armada375_data, }, { - .compatible = "marvell,armada375-z1-thermal", - .data = &armada375_data, - }, - { .compatible = "marvell,armada380-thermal", .data = &armada380_data, },Signature · 1 line
2.1.0
PATCH 1/2 thermal: armada: Remove support for A375-Z1 SoC
In reply to Ezequiel GarciaEzequiel and Jason,
Quoted 10 lines · Jason Cooper
Quoted 8 lines · Ezequiel Garcia
The Armada 375 Z1 SoC revision is no longer supported. This commit removes the quirk needed for the thermal sensor.
Signed-off-by Ezequiel Garcia <[email protected]>--- .../devicetree/bindings/thermal/armada-thermal.txt | 8 -------- drivers/thermal/armada_thermal.c | 20 -------------------- 2 files changed, 28 deletions(-)
Quoted 6 lines
As Thomas and Ezequiel rightfully mentioned, the compatible string below has never been in a dts file. Our arch code detected the Z1, and changed the compatible on the fly. As a result, there shouldn't be any dtbs in the wild with this compatible string. If there are, it will be held by the few developers (Marvell, partners) that know what they are doing.
First of, I would like to mention that best thing to avoid such situation is to be careful when documenting dt entries that represent hw that no one has access to (except internal people).
Quoted 3 lines
Acked-by Jason Cooper <[email protected]>
OK Jason. I saw you picked patch 2. Does it mean I can queue this one?
BR,
Eduardo Valentin
Quoted 76 lines
thx,
Jason.
Quoted 72 lines
Documentation/devicetree/bindings/thermal/armada-thermal.txt +0
-8@@ -5,17 +5,9 @@ Required properties: - compatible: Should be set to one of the following: marvell,armada370-thermal marvell,armada375-thermal - marvell,armada375-z1-thermal marvell,armada380-thermal marvell,armadaxp-thermal - Note: As the name suggests, "marvell,armada375-z1-thermal" - applies for the SoC Z1 stepping only. On such stepping - some quirks need to be done and the register offset differs - from the one in the A0 stepping. - The operating system may auto-detect the SoC stepping and - update the compatible and register offsets at runtime. - - reg: Device's register space. Two entries are expected, see the examples below. The first one is required for the sensor register;drivers/thermal/armada_thermal.c +0
-20@@ -35,10 +35,6 @@#define PMU_TDC0_OTF_CAL_MASK (0x1 << 30)#define PMU_TDC0_START_CAL_MASK (0x1 << 25) -#define A375_Z1_CAL_RESET_LSB 0x8011e214 -#define A375_Z1_CAL_RESET_MSB 0x30a88019 -#define A375_Z1_WORKAROUND_BIT BIT(9) -#define A375_UNIT_CONTROL_SHIFT 27#define A375_UNIT_CONTROL_MASK 0x7#define A375_READOUT_INVERT BIT(15)@@ -124,24 +120,12 @@ static void armada375_init_sensor(struct platform_device *pdev, struct armada_thermal_priv *priv) {unsigned long reg; -bool quirk_needed = - !!of_device_is_compatible (pdev->dev.of_node, -"marvell,armada375-z1-thermal" ); - -if (quirk_needed) { -/* Ensure these registers have the default (reset) values */ -writel (A375_Z1_CAL_RESET_LSB , priv->control); -writel (A375_Z1_CAL_RESET_MSB , priv->control +0x4 ); - } reg =readl (priv->control +4 ); reg &= ~(A375_UNIT_CONTROL_MASK <<A375_UNIT_CONTROL_SHIFT ); reg &= ~A375_READOUT_INVERT ; reg &= ~A375_HW_RESETn; -if (quirk_needed) - reg |=A375_Z1_WORKAROUND_BIT ; -writel (reg, priv->control +4 );mdelay (20 );@@ -260,10 +244,6 @@ static const struct of_device_id armada_thermal_id_table[] = { .data = &armada375_data, }, { - .compatible = "marvell,armada375-z1-thermal", - .data = &armada375_data, - }, - { .compatible = "marvell,armada380-thermal", .data = &armada380_data,
Quoted 8 lines
Quoted 4 lines
drivers/thermal/armada_thermal.c +0
-0},Signature · 1 line
2.1.0--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141120/8a096fb4/attachment.sig>
PATCH 1/2 thermal: armada: Remove support for A375-Z1 SoC
Quoted 20 lines · Eduardo Valentin
Ezequiel and Jason,
Quoted 10 lines · Jason Cooper
Quoted 8 lines · Ezequiel Garcia
The Armada 375 Z1 SoC revision is no longer supported. This commit removes the quirk needed for the thermal sensor.
Signed-off-by Ezequiel Garcia <[email protected]>--- .../devicetree/bindings/thermal/armada-thermal.txt | 8 -------- drivers/thermal/armada_thermal.c | 20 -------------------- 2 files changed, 28 deletions(-)Quoted 6 lines
As Thomas and Ezequiel rightfully mentioned, the compatible string below has never been in a dts file. Our arch code detected the Z1, and changed the compatible on the fly. As a result, there shouldn't be any dtbs in the wild with this compatible string. If there are, it will be held by the few developers (Marvell, partners) that know what they are doing.
Quoted 3 lines
First of, I would like to mention that best thing to avoid such situation is to be careful when documenting dt entries that represent hw that no one has access to (except internal people).
Agreed, mainline support for an SoC so early in it's lifetime was new for all of us. Lesson learned.
Quoted 5 lines
Quoted 3 lines
Acked-by Jason Cooper <[email protected]>OK Jason. I saw you picked patch 2. Does it mean I can queue this one?
Yep. Take it away.
thx,
Jason.
PATCH 1/2 thermal: armada: Remove support for A375-Z1 SoC
Dear Jason Cooper,
Quoted 6 lines · Jason Cooper
Quoted 3 lines
First of, I would like to mention that best thing to avoid such situation is to be careful when documenting dt entries that represent hw that no one has access to (except internal people).
Agreed, mainline support for an SoC so early in it's lifetime was new for all of us. Lesson learned.
So the suggestion would be to not document the DT bindings at all, until we reach a "stable" hardware that is distributed externally?
Note that the Z1 stepping is not completely internal: a small selection of early customers have access to it. But it normally never ends up in final products, it's aimed at allowing those early customers to start their development soon.
I don't mind adjusting how DT bindings are documented for such early SoCs stepping. But I really believe it's important to have a way to handle this situation nicely: we've been asking for years SoC vendors to start upstreaming their code early. Now that they start to do it, we shouldn't complain and instead adapt to this situation :-)
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/2 thermal: armada: Remove support for A375-Z1 SoC
Quoted 8 lines · Thomas Petazzoni
Dear Jason Cooper,
Quoted 4 lines · Jason Cooper
Quoted 3 lines
First of, I would like to mention that best thing to avoid such situation is to be careful when documenting dt entries that represent hw that no one has access to (except internal people).
Quoted 5 lines
Quoted 2 lines
Agreed, mainline support for an SoC so early in it's lifetime was new for all of us. Lesson learned.
So the suggestion would be to not document the DT bindings at all, until we reach a "stable" hardware that is distributed externally?
No, I think it's better to document. However, we should also document the fact that the binding is for an early version of the SoC and subject to incompatible change once the production version of the SoC is released. ie, an un-stable binding.
thx,
Jason.
Quoted 5 lines
I don't mind adjusting how DT bindings are documented for such early SoCs stepping. But I really believe it's important to have a way to handle this situation nicely: we've been asking for years SoC vendors to start upstreaming their code early. Now that they start to do it, we shouldn't complain and instead adapt to this situation :-)
Does the above proposal meet your expectations?
thx,
Jason.
PATCH 1/2 thermal: armada: Remove support for A375-Z1 SoC
Hello,
Quoted 7 lines · Jason Cooper
Quoted 2 lines
So the suggestion would be to not document the DT bindings at all, until we reach a "stable" hardware that is distributed externally?
No, I think it's better to document. However, we should also document the fact that the binding is for an early version of the SoC and subject to incompatible change once the production version of the SoC is released. ie, an un-stable binding.
Sounds good.
Quoted 7 lines
Quoted 5 lines
I don't mind adjusting how DT bindings are documented for such early SoCs stepping. But I really believe it's important to have a way to handle this situation nicely: we've been asking for years SoC vendors to start upstreaming their code early. Now that they start to do it, we shouldn't complain and instead adapt to this situation :-)
Does the above proposal meet your expectations?
Absolutely!
Thanks,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 2/2 ARM: mvebu: Remove thermal quirk for A375 Z1 revision
In reply to Ezequiel GarciaThe Armada 375 Z1 SoC revision is no longer supported. This commit removes the quirk required to "fix" the reg property and the compatible string of the thermal devicetree node.
--- arch/arm/mach-mvebu/board-v7.c | 66 +----------------------------------------- 1 file changed, 1 insertion(+), 65 deletions(-)
arch/arm/mach-mvebu/board-v7.c +1 -65
@@ -124,76 +124,12 @@ static void __init i2c_quirk(void)return ; } -#define A375_Z1_THERMAL_FIXUP_OFFSET 0xc - -static void __init thermal_quirk (void ) -{ -struct device_node *np; -u32 dev, rev; -int res; - -/* -* The early SoC Z1 revision needs a quirk to be applied in order -* for the thermal controller to work properly. This quirk breaks -* the thermal support if applied on a SoC that doesn't need it, -* so we enforce the SoC revision to be known. -*/ - res =mvebu_get_soc_id (&dev, &rev); -if (res <0 || (res ==0 && rev >ARMADA_375_Z1_REV )) -return ; - -for_each_compatible_node (np,NULL ,"marvell,armada375-thermal" ) { -struct property *prop; -__be32 newval, *newprop, *oldprop; -int len; - -/* -* The register offset is at a wrong location. This quirk -* creates a new reg property as a clone of the previous -* one and corrects the offset. -*/ - oldprop = (__be32 *)of_get_property (np,"reg" , &len); -if (!oldprop) -continue ; - -/* Create a duplicate of the 'reg' property */ - prop =kzalloc (sizeof (*prop),GFP_KERNEL ); - prop->length = len; - prop->name =kstrdup ("reg" ,GFP_KERNEL ); - prop->value =kzalloc (len,GFP_KERNEL ); -memcpy (prop->value, oldprop, len); - -/* Fixup the register offset of the second entry */ - oldprop +=2 ; - newprop = (__be32 *)prop->value +2 ; - newval =cpu_to_be32 (be32_to_cpu (*oldprop) - -A375_Z1_THERMAL_FIXUP_OFFSET ); - *newprop = newval; -of_update_property (np, prop); - -/* -* The thermal controller needs some quirk too, so let's change -* the compatible string to reflect this and allow the driver -* the take the necessary action. -*/ - prop =kzalloc (sizeof (*prop),GFP_KERNEL ); - prop->name =kstrdup ("compatible" ,GFP_KERNEL ); - prop->length =sizeof ("marvell,armada375-z1-thermal" ); - prop->value =kstrdup ("marvell,armada375-z1-thermal" , -GFP_KERNEL ); -of_update_property (np, prop); - } -return ; -} -static void __init mvebu_dt_init (void ) {if (of_machine_is_compatible ("plathome,openblocks-ax3-4" ))i2c_quirk (); -if (of_machine_is_compatible ("marvell,a375-db" )) { +if (of_machine_is_compatible ("marvell,a375-db" ))external_abort_quirk (); -thermal_quirk (); - }of_platform_populate (NULL , of_default_bus_match_table,NULL ,NULL ); }
Signature · 1 line
2.1.0
Jason Cooper
AppliedPATCH 2/2 ARM: mvebu: Remove thermal quirk for A375 Z1 revision
Quoted 8 lines · Ezequiel Garcia
The Armada 375 Z1 SoC revision is no longer supported. This commit removes the quirk required to "fix" the reg property and the compatible string of the thermal devicetree node.
Signed-off-by Ezequiel Garcia <[email protected]>--- arch/arm/mach-mvebu/board-v7.c | 66 +----------------------------------------- 1 file changed, 1 insertion(+), 65 deletions(-)
Applied to mvebu/soc
thx,
Jason.