lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 17 Feb 2020 09:35:45 +0100 From: Alexandre Torgue <alexandre.torgue@...com> To: Andy Shevchenko <andy.shevchenko@...il.com>, Kishon Vijay Abraham I <kishon@...com> CC: youling 257 <youling257@...il.com>, Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, USB <linux-usb@...r.kernel.org>, <saravanak@...gle.com> Subject: Re: [PATCH] phy: core: Add consumer device link support Hi, On 2/14/20 7:46 PM, Andy Shevchenko wrote: > On Mon, Feb 10, 2020 at 1:32 PM Alexandre Torgue > <alexandre.torgue@...com> wrote: >> On 2/10/20 9:08 AM, Kishon Vijay Abraham I wrote: >>> On 07/02/20 12:27 PM, youling 257 wrote: >>>> test this diff, dwc3 work for my device, thanks. >>>> >>>> 2020-02-07 13:16 GMT+08:00, Kishon Vijay Abraham I <kishon@...com>: >>>>> On 06/02/20 7:09 PM, youling257 wrote: >>>>>> This patch cause "dwc3 dwc3.3.auto: failed to create device link to >>>>>> dwc3.3.auto.ulpi" problem. >>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=206435 > > +1 to the report. > Please revert for v5.6 or provide a fix ASAP! > Kishon, do you plan to do the fix? If not, I'll send it quickly. Thanks Alex >>>>> >>>>> I'm suspecting there is some sort of reverse dependency with dwc3 ULPI. >>>>> Can you try the following diff? >>>>> >>>>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c >>>>> index 2eb28cc2d2dc..397311dcb116 100644 >>>>> --- a/drivers/phy/phy-core.c >>>>> +++ b/drivers/phy/phy-core.c >>>>> @@ -687,7 +687,7 @@ struct phy *phy_get(struct device *dev, const char >>>>> *string) >>>>> >>>>> get_device(&phy->dev); >>>>> >>>>> - link = device_link_add(dev, &phy->dev, DL_FLAG_STATELESS); >>>>> + link = device_link_add(dev, &phy->dev, DL_FLAG_SYNC_STATE_ONLY); >>>>> if (!link) { >>>>> dev_err(dev, "failed to create device link to %s\n", >>>>> dev_name(phy->dev.parent)); >>>>> @@ -802,7 +802,7 @@ struct phy *devm_of_phy_get(struct device *dev, >>>>> struct device_node *np, >>>>> return phy; >>>>> } >>>>> >>>>> - link = device_link_add(dev, &phy->dev, DL_FLAG_STATELESS); >>>>> + link = device_link_add(dev, &phy->dev, DL_FLAG_SYNC_STATE_ONLY); >>>>> if (!link) { >>>>> dev_err(dev, "failed to create device link to %s\n", >>>>> dev_name(phy->dev.parent)); >>>>> @@ -851,7 +851,7 @@ 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); >>>>> + link = device_link_add(dev, &phy->dev, DL_FLAG_SYNC_STATE_ONLY); >>>>> if (!link) { >>>>> dev_err(dev, "failed to create device link to %s\n", >>>>> dev_name(phy->dev.parent));Parent >>> >>> Can you check if this doesn't affect the suspend/resume ordering? >> >> With this fix, suspend/resume ordering is broken on my side. What do you >> think to keep the STATELESS flag and to only display a warn if >> "device_link_add" returns an error ? It's not "smart" but it could >> solved our issue. >> >> As a lot of improvements have been recently done on device link topic by >> Saravana, we could check with him what is the way to follow. >> >> Regards >> Alex >> >>> >>> Thanks >>> Kishon >>> > > >
Powered by blists - more mailing lists