diff mbox series

hibernation reverts in 4.19.134: better alternative?

Message ID 20200720101522.GB13137@amd (mailing list archive)
State New, archived
Headers show
Series hibernation reverts in 4.19.134: better alternative? | expand

Commit Message

Pavel Machek July 20, 2020, 10:15 a.m. UTC 
Hi!

This is queued for 4.19.134-stable, reverting 3 patches. But it seems
better alternative is available...

commit f3e697b7b6f5e2c570226f8f8692fb7db57215ec
Author: Sasha Levin <sashal@kernel.org>
Date:   Fri Jul 17 12:58:32 2020 -0400

    Revert "usb/ohci-platform: Fix a warning when hibernating"
    
    This reverts commit c83258a757687ffccce37ed73dba56cc6d4b8a1b.
    
    Eugeniu Rosca writes:

...

    > - Backporting 987351e1ea7772 ("phy: core: Add consumer device
    >   link support") to v4.14.187 looks challenging enough, so probably not
    >   worth it. Anybody to contradict this?

Backporting 987351e1ea7772 to 4.4 may be "interesting", but backport
to 4.19 seems trivial, here, and it seems to work ok according to CIP
test suites:

https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/168487477

(You can simply apply 987351e1ea7772 ignoring one file that is not yet
present in 4.19.)

Eugeniu, can you verify this works for you?

Best regards,
								Pavel

Signed-off-by: Pavel Machek (CIP) <pavel@denx.de>

Comments

Eugeniu Rosca July 21, 2020, 6:50 a.m. UTC | #1 
Hi Pavel,

On Mon, Jul 20, 2020 at 12:15:22PM +0200, Pavel Machek wrote:
> This is queued for 4.19.134-stable, reverting 3 patches. But it seems
> better alternative is available...
> 
> commit f3e697b7b6f5e2c570226f8f8692fb7db57215ec
> Author: Sasha Levin <sashal@kernel.org>
> Date:   Fri Jul 17 12:58:32 2020 -0400
> 
>     Revert "usb/ohci-platform: Fix a warning when hibernating"
>     
>     This reverts commit c83258a757687ffccce37ed73dba56cc6d4b8a1b.
>     
>     Eugeniu Rosca writes:
> 
> ...
> 
>     > - Backporting 987351e1ea7772 ("phy: core: Add consumer device
>     >   link support") to v4.14.187 looks challenging enough, so probably not
>     >   worth it. Anybody to contradict this?
> 
> Backporting 987351e1ea7772 to 4.4 may be "interesting", but backport

Typo? 4.14 meant?

> to 4.19 seems trivial, here, and it seems to work ok according to CIP
> test suites:
> 
> https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/168487477
> 
> (You can simply apply 987351e1ea7772 ignoring one file that is not yet
> present in 4.19.)

Technically yes. Backporting 987351e1ea7772 to v4.19.x avoids the panic.
But it means integrating a v5.6 feature (isn't 987351e1ea7772 one?) into
the v4.19.x stable tree. Isn't v4.19.x (just like any other stable
branch) supposed to contain just fixes?

Should then any missing prerequisite features be pumped in into the
stable tree, whenever backporting a bugfix produces unexpected results?

FWIW I confirm that:
* setup [A] leads to the issue reported in [C]
* setup [B] resolves the issue reported in [C]

[A] v4.19 + 16bdc04cc98 + 1cb3b0095c3 + 79112cc3c29f
[B] v4.19 + 16bdc04cc98 + 1cb3b0095c3 + 79112cc3c29f + 987351e1ea7
[C] https://lore.kernel.org/linux-usb/20200709070023.GA18414@lxhi-065.adit-jv.com/
Pavel Machek July 21, 2020, 11:27 a.m. UTC | #2 
Hi!

> On Mon, Jul 20, 2020 at 12:15:22PM +0200, Pavel Machek wrote:
> > This is queued for 4.19.134-stable, reverting 3 patches. But it seems
> > better alternative is available...
> > 
> > commit f3e697b7b6f5e2c570226f8f8692fb7db57215ec
> > Author: Sasha Levin <sashal@kernel.org>
> > Date:   Fri Jul 17 12:58:32 2020 -0400
> > 
> >     Revert "usb/ohci-platform: Fix a warning when hibernating"
> >     
> >     This reverts commit c83258a757687ffccce37ed73dba56cc6d4b8a1b.
> >     
> >     Eugeniu Rosca writes:
> > 
> > ...
> > 
> >     > - Backporting 987351e1ea7772 ("phy: core: Add consumer device
> >     >   link support") to v4.14.187 looks challenging enough, so probably not
> >     >   worth it. Anybody to contradict this?
> > 
> > Backporting 987351e1ea7772 to 4.4 may be "interesting", but backport
> 
> Typo? 4.14 meant?

4.4 meant. I care about 4.4 and 4.19.

> > to 4.19 seems trivial, here, and it seems to work ok according to CIP
> > test suites:
> > 
> > https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/168487477
> > 
> > (You can simply apply 987351e1ea7772 ignoring one file that is not yet
> > present in 4.19.)
> 
> Technically yes. Backporting 987351e1ea7772 to v4.19.x avoids the panic.
> But it means integrating a v5.6 feature (isn't 987351e1ea7772 one?) into
> the v4.19.x stable tree. Isn't v4.19.x (just like any other stable
> branch) supposed to contain just fixes?

Well, backport might be preffered to reverting 3 patches that will
re-introduce WARN()s. Yes, documentation does not match reality here.

> Should then any missing prerequisite features be pumped in into the
> stable tree, whenever backporting a bugfix produces unexpected results?
> 
> FWIW I confirm that:
> * setup [A] leads to the issue reported in [C]
> * setup [B] resolves the issue reported in [C]

Thank you!

> [A] v4.19 + 16bdc04cc98 + 1cb3b0095c3 + 79112cc3c29f
> [B] v4.19 + 16bdc04cc98 + 1cb3b0095c3 + 79112cc3c29f + 987351e1ea7
> [C] https://lore.kernel.org/linux-usb/20200709070023.GA18414@lxhi-065.adit-jv.com/

Best regards,
								Pavel
diff mbox series

Patch

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 35fd38c5a4a1..600a4e554d17 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -33,7 +33,7 @@  static void devm_phy_release(struct device *dev, void *res)
 {
 	struct phy *phy = *(struct phy **)res;
 
-	phy_put(phy);
+	phy_put(dev, phy);
 }
 
 static void devm_phy_provider_release(struct device *dev, void *res)
@@ -490,12 +490,12 @@  struct phy *of_phy_get(struct device_node *np, const char *con_id)
 EXPORT_SYMBOL_GPL(of_phy_get);
 
 /**
- * phy_put() - release the PHY
- * @phy: the phy returned by phy_get()
+ * of_phy_put() - release the PHY
+ * @phy: the phy returned by of_phy_get()
  *
- * Releases a refcount the caller received from phy_get().
+ * Releases a refcount the caller received from of_phy_get().
  */
-void phy_put(struct phy *phy)
+void of_phy_put(struct phy *phy)
 {
 	if (!phy || IS_ERR(phy))
 		return;
@@ -503,6 +503,20 @@  void phy_put(struct phy *phy)
 	module_put(phy->ops->owner);
 	put_device(&phy->dev);
 }
+EXPORT_SYMBOL_GPL(of_phy_put);
+
+/**
+ * phy_put() - release the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by phy_get()
+ *
+ * Releases a refcount the caller received from phy_get().
+ */
+void phy_put(struct device *dev, struct phy *phy)
+{
+	device_link_remove(dev, &phy->dev);
+	of_phy_put(phy);
+}
 EXPORT_SYMBOL_GPL(phy_put);
 
 /**
@@ -570,6 +584,7 @@  struct phy *phy_get(struct device *dev, const char *string)
 {
 	int index = 0;
 	struct phy *phy;
+	struct device_link *link;
 
 	if (string == NULL) {
 		dev_WARN(dev, "missing string\n");
@@ -591,6 +606,13 @@  struct phy *phy_get(struct device *dev, const char *string)
 
 	get_device(&phy->dev);
 
+	link = device_link_add(dev, &phy->dev, DL_FLAG_STATELESS);
+	if (!link) {
+		dev_err(dev, "failed to create device link to %s\n",
+			dev_name(phy->dev.parent));
+		return ERR_PTR(-EINVAL);
+	}
+
 	return phy;
 }
 EXPORT_SYMBOL_GPL(phy_get);
@@ -684,6 +706,7 @@  struct phy *devm_of_phy_get(struct device *dev, struct device_node *np,
 			    const char *con_id)
 {
 	struct phy **ptr, *phy;
+	struct device_link *link;
 
 	ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
 	if (!ptr)
@@ -695,6 +718,14 @@  struct phy *devm_of_phy_get(struct device *dev, struct device_node *np,
 		devres_add(dev, ptr);
 	} else {
 		devres_free(ptr);
+		return phy;
+	}
+
+	link = device_link_add(dev, &phy->dev, DL_FLAG_STATELESS);
+	if (!link) {
+		dev_err(dev, "failed to create device link to %s\n",
+			dev_name(phy->dev.parent));
+		return ERR_PTR(-EINVAL);
 	}
 
 	return phy;
@@ -717,6 +748,7 @@  struct phy *devm_of_phy_get_by_index(struct device *dev, struct device_node *np,
 				     int index)
 {
 	struct phy **ptr, *phy;
+	struct device_link *link;
 
 	ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
 	if (!ptr)
@@ -738,6 +770,13 @@  struct phy *devm_of_phy_get_by_index(struct device *dev, struct device_node *np,
 	*ptr = phy;
 	devres_add(dev, ptr);
 
+	link = device_link_add(dev, &phy->dev, DL_FLAG_STATELESS);
+	if (!link) {
+		dev_err(dev, "failed to create device link to %s\n",
+			dev_name(phy->dev.parent));
+		return ERR_PTR(-EINVAL);
+	}
+
 	return phy;
 }
 EXPORT_SYMBOL_GPL(devm_of_phy_get_by_index);
diff --git a/drivers/usb/renesas_usbhs/rcar2.c b/drivers/usb/renesas_usbhs/rcar2.c
index 0027092b1118..c52d36c384e7 100644
--- a/drivers/usb/renesas_usbhs/rcar2.c
+++ b/drivers/usb/renesas_usbhs/rcar2.c
@@ -33,7 +33,7 @@  static int usbhs_rcar2_hardware_exit(struct platform_device *pdev)
 	struct usbhs_priv *priv = usbhs_pdev_to_priv(pdev);
 
 	if (priv->phy) {
-		phy_put(priv->phy);
+		phy_put(&pdev->dev, priv->phy);
 		priv->phy = NULL;
 	}
 
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 9713aebdd348..e969b604cb54 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -185,7 +185,8 @@  struct phy *devm_of_phy_get(struct device *dev, struct device_node *np,
 			    const char *con_id);
 struct phy *devm_of_phy_get_by_index(struct device *dev, struct device_node *np,
 				     int index);
-void phy_put(struct phy *phy);
+void of_phy_put(struct phy *phy);
+void phy_put(struct device *dev, struct phy *phy);
 void devm_phy_put(struct device *dev, struct phy *phy);
 struct phy *of_phy_get(struct device_node *np, const char *con_id);
 struct phy *of_phy_simple_xlate(struct device *dev,
@@ -348,7 +349,11 @@  static inline struct phy *devm_of_phy_get_by_index(struct device *dev,
 	return ERR_PTR(-ENOSYS);
 }
 
-static inline void phy_put(struct phy *phy)
+static inline void of_phy_put(struct phy *phy)
+{
+}
+
+static inline void phy_put(struct device *dev, struct phy *phy)
 {
 }