[PATCH v2 0/2] pinctrl: pinctrl-zynqmp: Revert output-enable and bias-high-impedance support

[PATCH v2 0/2] pinctrl: pinctrl-zynqmp: Revert output-enable and bias-high-impedance support

[Sai Krishna Potthuri]

Having support for output-enable and bias-high-impedance properties
causing system hang with older Xilinx ZynqMP Platform Management Firmware
because there is missing autodetection feature.
When this feature is implemented, support for these two properties should
bring back.

changes in v2:
-> Added stable tree tag in 1/2 and 2/2 patches.

Sai Krishna Potthuri (2):
  Revert "pinctrl: pinctrl-zynqmp: Add support for output-enable and
    bias-high-impedance"
  Revert "dt-bindings: pinctrl-zynqmp: Add output-enable configuration"

 .../devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 4 ----
 drivers/pinctrl/pinctrl-zynqmp.c                         | 9 ---------
 2 files changed, 13 deletions(-)

-- 
2.17.1

[PATCH v2 1/2] Revert "pinctrl: pinctrl-zynqmp: Add support for output-enable and bias-high-impedance"

[Sai Krishna Potthuri]

This reverts commit ad2bea79ef0144043721d4893eef719c907e2e63.

On systems with older PMUFW (Xilinx ZynqMP Platform Management Firmware)
using these pinctrl properties can cause system hang because there is
missing feature autodetection.
When this feature is implemented in the PMUFW, support for these two
properties should bring back.

Cc: stable@vger.kernel.org
Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
---
 drivers/pinctrl/pinctrl-zynqmp.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-zynqmp.c b/drivers/pinctrl/pinctrl-zynqmp.c
index 7d2fbf8a02cd..c98f35ad8921 100644
--- a/drivers/pinctrl/pinctrl-zynqmp.c
+++ b/drivers/pinctrl/pinctrl-zynqmp.c
@@ -412,10 +412,6 @@ static int zynqmp_pinconf_cfg_set(struct pinctrl_dev *pctldev,
 
 			break;
 		case PIN_CONFIG_BIAS_HIGH_IMPEDANCE:
-			param = PM_PINCTRL_CONFIG_TRI_STATE;
-			arg = PM_PINCTRL_TRI_STATE_ENABLE;
-			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
-			break;
 		case PIN_CONFIG_MODE_LOW_POWER:
 			/*
 			 * These cases are mentioned in dts but configurable
@@ -424,11 +420,6 @@ static int zynqmp_pinconf_cfg_set(struct pinctrl_dev *pctldev,
 			 */
 			ret = 0;
 			break;
-		case PIN_CONFIG_OUTPUT_ENABLE:
-			param = PM_PINCTRL_CONFIG_TRI_STATE;
-			arg = PM_PINCTRL_TRI_STATE_DISABLE;
-			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
-			break;
 		default:
 			dev_warn(pctldev->dev,
 				 "unsupported configuration parameter '%u'\n",
-- 
2.17.1

[PATCH v2 2/2] Revert "dt-bindings: pinctrl-zynqmp: Add output-enable configuration"

[Sai Krishna Potthuri]

This reverts commit 133ad0d9af99bdca90705dadd8d31c20bfc9919f.

On systems with older PMUFW (Xilinx ZynqMP Platform Management Firmware)
using these pinctrl properties can cause system hang because there is
missing feature autodetection.
When this feature is implemented, support for these two properties should
bring back.

Cc: stable@vger.kernel.org
Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
---
 .../devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml      | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
index 1e2b9b627b12..2722dc7bb03d 100644
--- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
@@ -274,10 +274,6 @@ patternProperties:
           slew-rate:
             enum: [0, 1]
 
-          output-enable:
-            description:
-              This will internally disable the tri-state for MIO pins.
-
           drive-strength:
             description:
               Selects the drive strength for MIO pins, in mA.
-- 
2.17.1

Re: [PATCH v2 2/2] Revert "dt-bindings: pinctrl-zynqmp: Add output-enable configuration"

[Rob Herring]

On Mon, Oct 17, 2022 at 06:33:03PM +0530, Sai Krishna Potthuri wrote:
> This reverts commit 133ad0d9af99bdca90705dadd8d31c20bfc9919f.
> 
> On systems with older PMUFW (Xilinx ZynqMP Platform Management Firmware)
> using these pinctrl properties can cause system hang because there is
> missing feature autodetection.
> When this feature is implemented, support for these two properties should
> bring back.

So I'm going to get to review the revert of the revert at some point? 
Why do the properties need to be removed from the binding? They work on 
'not older' firmware, right? Isn't just removing the driver support or 
removing from .dts files enough?

Rob

Re: [PATCH v2 2/2] Revert "dt-bindings: pinctrl-zynqmp: Add output-enable configuration"

[Michal Simek]

Hi Rob,

On 10/21/22 03:11, Rob Herring wrote:
> On Mon, Oct 17, 2022 at 06:33:03PM +0530, Sai Krishna Potthuri wrote:
>> This reverts commit 133ad0d9af99bdca90705dadd8d31c20bfc9919f.
>>
>> On systems with older PMUFW (Xilinx ZynqMP Platform Management Firmware)
>> using these pinctrl properties can cause system hang because there is
>> missing feature autodetection.
>> When this feature is implemented, support for these two properties should
>> bring back.
> 
> So I'm going to get to review the revert of the revert at some point?
> Why do the properties need to be removed from the binding? They work on
> 'not older' firmware, right? Isn't just removing the driver support or
> removing from .dts files enough?

Removing functionality should be IMHO enough. Maybe make sense to inform users 
that there is missing functionality where they define these properties via DT.

Thanks,
Michal

Re: [PATCH v2 0/2] pinctrl: pinctrl-zynqmp: Revert output-enable and bias-high-impedance support

[Michal Simek]

On 10/17/22 15:03, Sai Krishna Potthuri wrote:
> Having support for output-enable and bias-high-impedance properties
> causing system hang with older Xilinx ZynqMP Platform Management Firmware
> because there is missing autodetection feature.
> When this feature is implemented, support for these two properties should
> bring back.
> 
> changes in v2:
> -> Added stable tree tag in 1/2 and 2/2 patches.
> 
> Sai Krishna Potthuri (2):
>    Revert "pinctrl: pinctrl-zynqmp: Add support for output-enable and
>      bias-high-impedance"
>    Revert "dt-bindings: pinctrl-zynqmp: Add output-enable configuration"
> 
>   .../devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 4 ----
>   drivers/pinctrl/pinctrl-zynqmp.c                         | 9 ---------
>   2 files changed, 13 deletions(-)
> 

Acked-by: Michal Simek <michal.simek@amd.com>

Thanks,
Michal

Re: [PATCH v2 0/2] pinctrl: pinctrl-zynqmp: Revert output-enable and bias-high-impedance support

[Linus Walleij]

On Mon, Oct 17, 2022 at 3:03 PM Sai Krishna Potthuri
<sai.krishna.potthuri@amd.com> wrote:

> Having support for output-enable and bias-high-impedance properties
> causing system hang with older Xilinx ZynqMP Platform Management Firmware
> because there is missing autodetection feature.
> When this feature is implemented, support for these two properties should
> bring back.
>
> changes in v2:
> -> Added stable tree tag in 1/2 and 2/2 patches.

Patches applied for fixes!

Thanks for dealing with this, I hope you find a proper way to make
it work with all firmwares.

Yours,
Linus Walleij

Re: [PATCH v2 0/2] pinctrl: pinctrl-zynqmp: Revert output-enable and bias-high-impedance support

[Michal Simek]

On 10/18/22 09:51, Linus Walleij wrote:
> On Mon, Oct 17, 2022 at 3:03 PM Sai Krishna Potthuri
> <sai.krishna.potthuri@amd.com> wrote:
> 
>> Having support for output-enable and bias-high-impedance properties
>> causing system hang with older Xilinx ZynqMP Platform Management Firmware
>> because there is missing autodetection feature.
>> When this feature is implemented, support for these two properties should
>> bring back.
>>
>> changes in v2:
>> -> Added stable tree tag in 1/2 and 2/2 patches.
> 
> Patches applied for fixes!
> 
> Thanks for dealing with this, I hope you find a proper way to make
> it work with all firmwares.

The way what pmufw team described is that driver will ask firmware if that 
feature is available or not. If yes, the current calls will be made. Maybe we 
could do it via module parameter but this is the cleanest solution for now.

Thanks,
Michal