hibernation reverts in 4.19.134: better alternative?
Subsystems (3)
Hi!
This is queued for 4.19.134-stable, reverting 3 patches. But it seems better alternative is available...
commit f3e697b7b6f5e2c570226f8f8692fb7db57215ec
Author: Sasha Levin <[email protected]> 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:
...
Quoted 3 lines
- 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
drivers/phy/phy-core.c +44 -5
@@ -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);
drivers/usb/renesas_usbhs/rcar2.c +1 -1
@@ -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 ; }
include/linux/phy/phy.h +7 -2
@@ -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) { }
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi Pavel,
Quoted 13 lines · Pavel Machek
This is queued for 4.19.134-stable, reverting 3 patches. But it seems better alternative is available...
commit
f3e697b7b6f5e2c570226f8f8692fb7db57215ecAuthor: Sasha Levin <[email protected]> Date: Fri Jul 17 12:58:32 2020 -0400Revert "usb/ohci-platform: Fix a warning when hibernating"
This reverts commit
c83258a757687ffccce37ed73dba56cc6d4b8a1b.Eugeniu Rosca writes:
Quoted 7 lines
...
Quoted 3 lines
- 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
987351e1ea7772to 4.4 may be "interesting", but backport
Typo? 4.14 meant?
Quoted 7 lines
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
987351e1ea7772ignoring 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/[email protected]/
Signature · 2 lines
Best regards, Eugeniu Rosca
Hi!
Quoted 16 lines · Pavel Machek
Quoted 15 lines
This is queued for 4.19.134-stable, reverting 3 patches. But it seems better alternative is available...
commit
f3e697b7b6f5e2c570226f8f8692fb7db57215ecAuthor: Sasha Levin <[email protected]> Date: Fri Jul 17 12:58:32 2020 -0400Revert "usb/ohci-platform: Fix a warning when hibernating"
This reverts commit
c83258a757687ffccce37ed73dba56cc6d4b8a1b.Eugeniu Rosca writes:
...
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
- 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
987351e1ea7772to 4.4 may be "interesting", but backportTypo? 4.14 meant?
4.4 meant. I care about 4.4 and 4.19.
Quoted 5 lines
Quoted 5 lines
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
Quoted 7 lines
Quoted 2 lines
(You can simply apply
987351e1ea7772ignoring one file that is not yet present in 4.19.)Technically yes. Backporting
987351e1ea7772to v4.19.x avoids the panic. But it means integrating a v5.6 feature (isn't987351e1ea7772one?) 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.
Quoted 6 lines
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!
Quoted 3 lines
[A] v4.19 +
16bdc04cc98+1cb3b0095c3+79112cc3c29f
[B] v4.19 +16bdc04cc98+1cb3b0095c3+79112cc3c29f+987351e1ea7
[C] https://lore.kernel.org/linux-usb/[email protected]/
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany