enable reset_control_reset for shared reset lines

Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line.

This patch allows using reset_control_reset also for shared resets. There are limitations though:
reset_control_reset can only be used if reset_control_assert was not used yet.
reset_control_assert can only be used if reset_control_reset was not used yet.
For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case).

Signed-off-by Martin Blumenstingl <[email protected]>

---
 drivers/reset/core.c | 31 +++++++++++++++++++++++++------
 1 file changed, 25 insertions(+), 6 deletions(-)

drivers/reset/core.c +0 -0

index 395dc9c..1565348 100644

drivers/reset/core.c +1 -0

  */
 struct reset_control {
 	struct reset_controller_dev *rcdev;

@@ -40,6 +41,7 @@ struct reset_control {
 	unsigned int refcnt;
 	int shared;
 	atomic_t deassert_count;
+	atomic_t triggered_count;
 };
 
 /**

drivers/reset/core.c +1 -2

  */
 int reset_control_reset(struct reset_control *rstc)
 {
-	if (WARN_ON(rstc->shared))
-		return -EINVAL;
+	int ret;

drivers/reset/core.c +5 -0

+
+	return ret;
 }
 EXPORT_SYMBOL_GPL(reset_control_reset);
 

@@ -165,6 +178,9 @@ int reset_control_assert(struct reset_control *rstc)
 		return -ENOTSUPP;
 
 	if (rstc->shared) {
+		if (WARN_ON(atomic_read(&rstc->triggered_count) != 0))
+			return -EINVAL;
+
 		if (WARN_ON(atomic_read(&rstc->deassert_count) == 0))
 			return -EINVAL;
 

Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line.

This patch allows using reset_control_reset also for shared resets. There are limitations though:
reset_control_reset can only be used if reset_control_assert was not used yet.
reset_control_assert can only be used if reset_control_reset was not used yet.
For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case).

Signed-off-by Martin Blumenstingl <[email protected]>

---
 drivers/reset/core.c | 43 +++++++++++++++++++++++++++++++++++++------
 1 file changed, 37 insertions(+), 6 deletions(-)

drivers/reset/core.c +37 -6

index b8ae1db..10368ed 100644
@@ -32,6 +32,9 @@ static LIST_HEAD(reset_controller_list);
  * @refcnt: Number of gets of this reset_control
  * @shared: Is this a shared (1), or an exclusive (0) reset_control?
  * @deassert_cnt: Number of times this reset line has been deasserted
+ * @triggered_count: Number of times this reset line has been reset. Currently
+ *                   only used for shared resets, which means that the value
+ *                   will be either 0 or 1.
  */
 struct reset_control {
 	struct reset_controller_dev *rcdev;

@@ -40,6 +43,7 @@ struct reset_control {
 	unsigned int refcnt;
 	int shared;
 	atomic_t deassert_count;
+	atomic_t triggered_count;
 };
 
 /**

@@ -134,18 +138,35 @@ EXPORT_SYMBOL_GPL(devm_reset_controller_register);
  * reset_control_reset - reset the controlled device
  * @rstc: reset controller
  *
- * Calling this on a shared reset controller is an error.
+ * On a shared reset line the actual reset pulse is only triggered once for the
+ * lifetime of the reset_control instance: for all but the first caller this is
+ * a no-op.
+ * Consumers must not use reset_control_(de)assert on shared reset lines when
+ * reset_control_reset has been used.
  */
 int reset_control_reset(struct reset_control *rstc)
 {
-	if (WARN_ON(IS_ERR_OR_NULL(rstc)) ||
-	    WARN_ON(rstc->shared))
+	int ret;
+
+	if (WARN_ON(IS_ERR_OR_NULL(rstc)))
 		return -EINVAL;
 
-	if (rstc->rcdev->ops->reset)
-		return rstc->rcdev->ops->reset(rstc->rcdev, rstc->id);
+	if (!rstc->rcdev->ops->reset)
+		return -ENOTSUPP;
 
-	return -ENOTSUPP;
+	if (rstc->shared) {
+		if (WARN_ON(atomic_read(&rstc->deassert_count) != 0))
+			return -EINVAL;
+
+		if (atomic_inc_return(&rstc->triggered_count) != 1)
+			return 0;
+	}
+
+	ret = rstc->rcdev->ops->reset(rstc->rcdev, rstc->id);
+	if (rstc->shared && !ret)
+		atomic_dec(&rstc->triggered_count);
+
+	return ret;
 }
 EXPORT_SYMBOL_GPL(reset_control_reset);
 

@@ -159,6 +180,8 @@ EXPORT_SYMBOL_GPL(reset_control_reset);
  *
  * For shared reset controls a driver cannot expect the hw's registers and
  * internal state to be reset, but must be prepared for this to happen.
+ * Consumers must not use reset_control_reset on shared reset lines when
+ * reset_control_(de)assert has been used.
  */
 int reset_control_assert(struct reset_control *rstc)
 {

@@ -169,6 +192,9 @@ int reset_control_assert(struct reset_control *rstc)
 		return -ENOTSUPP;
 
 	if (rstc->shared) {
+		if (WARN_ON(atomic_read(&rstc->triggered_count) != 0))
+			return -EINVAL;
+
 		if (WARN_ON(atomic_read(&rstc->deassert_count) == 0))
 			return -EINVAL;
 

@@ -185,6 +211,8 @@ EXPORT_SYMBOL_GPL(reset_control_assert);
  * @rstc: reset controller
  *
  * After calling this function, the reset is guaranteed to be deasserted.
+ * Consumers must not use reset_control_reset on shared reset lines when
+ * reset_control_(de)assert has been used.
  */
 int reset_control_deassert(struct reset_control *rstc)
 {

@@ -195,6 +223,9 @@ int reset_control_deassert(struct reset_control *rstc)
 		return -ENOTSUPP;
 
 	if (rstc->shared) {
+		if (WARN_ON(atomic_read(&rstc->triggered_count) != 0))
+			return -EINVAL;
+
 		if (atomic_inc_return(&rstc->deassert_count) != 1)
 			return 0;
 	}

Both PHYs are sharing one reset line. With recent improvements to the reset framework we can now also use reset_control_reset with shared resets.
This allows us to drop some workarounds where the reset was only specified for one PHY but not the other, to make sure that the reset it only executed once (as the reset framework was not able to use reset_control_reset with shared reset lines).

Signed-off-by Martin Blumenstingl <[email protected]>

---
 drivers/phy/phy-meson8b-usb2.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/phy/phy-meson8b-usb2.c +1 -2

index 73bf632..f1ee96a 100644
@@ -237,8 +237,7 @@ static int phy_meson8b_usb2_probe(struct platform_device *pdev)
 	if (IS_ERR(priv->clk_usb))
 		return PTR_ERR(priv->clk_usb);
 
-	priv->reset = devm_reset_control_get_optional_exclusive(&pdev->dev,
-								NULL);
+	priv->reset = devm_reset_control_get_optional_shared(&pdev->dev, NULL);
 	if (PTR_ERR(priv->reset) == -EPROBE_DEFER)
 		return PTR_ERR(priv->reset);
 

When the USB PHY driver was introduced the reset framework did not have support for triggering a reset pulse for shared resets. On GXBB however there is only one reset line for both PHYs (meaning we have a shared reset line). With the latest changes to the reset framework and the corresponding updates to the phy-meson8b-usb2 driver we can now pass the reset to the second PHY as well.

Signed-off-by Martin Blumenstingl <[email protected]>

Quoted 7 lines · Martin Blumenstingl

When the USB PHY driver was introduced the reset framework did not have support for triggering a reset pulse for shared resets. On GXBB however there is only one reset line for both PHYs (meaning we have a shared reset line). With the latest changes to the reset framework and the corresponding updates to the phy-meson8b-usb2 driver we can now pass the reset to the second PHY as well.

Quoted 1 line

Signed-off-by Martin Blumenstingl <[email protected]>

Applied.

Hi Kevin,

Quoted 9 lines · Kevin Hilman

Quoted 7 lines · Martin Blumenstingl

When the USB PHY driver was introduced the reset framework did not have support for triggering a reset pulse for shared resets. On GXBB however there is only one reset line for both PHYs (meaning we have a shared reset line). With the latest changes to the reset framework and the corresponding updates to the phy-meson8b-usb2 driver we can now pass the reset to the second PHY as well.

Quoted 3 lines

Quoted 1 line

Signed-off-by Martin Blumenstingl <[email protected]>

Applied.

Unfortunately I think I put crucial information only in the cover-letter's description:
"the dts patch has a runtime-dependency on patch 1 and 2"

So please feel free to keep or drop the patch as it is. In case you decide drop it I will re-send it for 4.11 (after all the 4.10 stuff is done).

Quoted 12 lines · Martin Blumenstingl

Hi Kevin,

Quoted 9 lines · Kevin Hilman

Quoted 7 lines · Martin Blumenstingl

When the USB PHY driver was introduced the reset framework did not have support for triggering a reset pulse for shared resets. On GXBB however there is only one reset line for both PHYs (meaning we have a shared reset line). With the latest changes to the reset framework and the corresponding updates to the phy-meson8b-usb2 driver we can now pass the reset to the second PHY as well.

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

Signed-off-by Martin Blumenstingl <[email protected]>

Applied.

Unfortunately I think I put crucial information only in the cover-letter's description:
"the dts patch has a runtime-dependency on patch 1 and 2"

I saw that, but also see that both of those have been queued, so should land in v4.10 also.

Quoted 3 lines

So please feel free to keep or drop the patch as it is. In case you decide drop it I will re-send it for 4.11 (after all the 4.10 stuff is done).

IMO, it's fine to keep it. That means there may be some versions of linux-next that have the problem where the reset will get asserted twice, but since that is affecting very few people (probably only you), I think it's OK, since it will be fine once v4.10-rc1 is released.

If you don't want that, let me know and I'll drop it for now.