From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: phy: work around 'phys' references to usb-phy devices From: Eric Anholt Message-Id: <87d12guups.fsf@anholt.net> Date: Thu, 11 Jan 2018 10:16:31 -0800 To: Arnd Bergmann , Kishon Vijay Abraham I Cc: Florian Fainelli , DTML , Linux ARM , Rob Herring , linux-usb@vger.kernel.org, "# 3.4.x" , Stefan Wahren , Felipe Balbi , Andrzej Pietrasiewicz , Linux Kernel Mailing List List-ID: QXJuZCBCZXJnbWFubiA8YXJuZEBhcm5kYi5kZT4gd3JpdGVzOgoKPiBPbiBUaHUsIEphbiAxMSwg MjAxOCBhdCAyOjMwIFBNLCBLaXNob24gVmlqYXkgQWJyYWhhbSBJIDxraXNob25AdGkuY29tPiB3 cm90ZToKPj4gT24gVGh1cnNkYXkgMTEgSmFudWFyeSAyMDE4IDAyOjI3IEFNLCBBcm5kIEJlcmdt YW5uIHdyb3RlOgo+Pj4gT24gTW9uLCBKYW4gOCwgMjAxOCBhdCA3OjMyIFBNLCBLaXNob24gVmlq YXkgQWJyYWhhbSBJIDxraXNob25AdGkuY29tPiB3cm90ZToKPj4+PiBPbiBNb25kYXkgMDggSmFu dWFyeSAyMDE4IDA2OjMxIFBNLCBBcm5kIEJlcmdtYW5uIHdyb3RlOgo+Pj4+PiBTdGVmYW4gV2Fo cmVuIHJlcG9ydHMgYSBwcm9ibGVtIHdpdGggYSB3YXJuaW5nIGZpeCB0aGF0IHdhcyBtZXJnZWQK Pj4+Pj4gLS0tCj4+Pj4+IFRoaXMgb2J2aW91c2x5IG5lZWRzIHRvIGJlIHRlc3RlZCwgSSB3cm90 ZSB0aGlzIHVwIGFzIGEgcmVwbHkgdG8KPj4+Pj4gU3RlZmFuJ3MgYnVnIHJlcG9ydC4gSSdtIGZh aXJseSBzdXJlIHRoYXQgSSBjb3ZlcmVkIGFsbCB1c2ItcGh5Cj4+Pj4+IGRyaXZlciBzdHJpbmdz IGhlcmUuIE15IGdvYWwgaXMgdG8gaGF2ZSBhIGZpeCBtZXJnZWQgaW50byA0LjE1Cj4+Pj4+IHJh dGhlciB0aGFuIHJldmVydGluZyBhbGwgdGhlIERUIGZpeGVzLgo+Pj4+Cj4+Pj4gU2hvdWxkbid0 IHRoZSBmaXggYmUgaW4gcGh5IGNvbnN1bWVyIGRyaXZlcnMgdG8gbm90IHJldHVybiBlcnJvciBp ZiBpdCdzIGFibGUKPj4+PiB0byBmaW5kIHRoZSBwaHkgZWl0aGVyIHVzaW5nIHVzYi1waHkgb3Ig Z2VuZXJpYyBwaHk/Cj4+Pgo+Pj4gU3RlZmFuIGhhcyBwb3N0ZWQgYSBwYXRjaCB0byB0aGF0IGVm ZmVjdCBub3csIGJ1dCBJIGZlYXIgdGhhdCBtaWdodCBiZQo+Pj4gYSBsaXR0bGUgZnJhZ2lsZSwg aW4gcGFydGljdWxhciB0aGlzIHNob3J0IGJlZm9yZSB0aGUgcmVsZWFzZSB3aXRoIHRoZQo+Pj4g cmVncmVzc2lvbgo+Pj4gaW4gcGxhY2UuCj4+Pgo+Pj4gVGhlIG1haW4gcHJvYmxlbSBpcyB0aGF0 IHdlJ2QgaGF2ZSB0byBjaGFuZ2UgdGhlIGdlbmVyaWMKPj4+IHVzYl9hZGRfaGNkKCkgZnVuY3Rp b24gaW4gYWRkaXRpb24gdG8gZHdjMiBhbmQgZHdjMyB0byBpZ25vcmUKPj4+IC1FUFJPQkVfREVG RVIgZnJvbSBwaHlfZ2V0KCkgd2hlbmV2ZXIgdXNiX2dldF9waHlfZGV2KCkKPj4+IGhhcyBhbHJl YWR5IHN1Y2NlZWRlZC4KPj4+Cj4+PiBJZiB0aGVyZSBpcyBhbnkgSENEIHRoYXQgcmVsaWVzIG9u IHVzYl9hZGRfaGNkKCkgdG8gZ2V0IGJvdGggdGhlCj4+PiB1c2JfcGh5IGFuZCB0aGUgcGh5IHN0 cnVjdHVyZXMsIGFuZCBpdCBtYXkgbmVlZCB0byBkZWZlciBwcm9iaW5nCj4+PiB3aGVuIHRoZSBs YXR0ZXIgb25lIGlzbid0IHJlYWR5IHlldCwgdGhhdCBmaXggd291bGQgYnJlYWsgYW5vdGhlcgo+ Pj4gZHJpdmVyLgo+Pgo+PiBobW0uLiBJTU8gdGhlIGJldHRlciB0aGluZyByaWdodCBub3cgd291 bGQgYmUgdG8gcmV2ZXJ0IHRoZSBkdCBwYXRjaCB3aGljaCBhZGRzCj4+ICNwaHktY2VsbHMuCj4+ IFdlIGhhdmUgdG8gc2VlIGlmIHRoZXJlIGFyZSBiZXR0ZXIgZml4ZXMgaW4gb3JkZXIgdG8gYWRk ICNwaHktY2VsbHMgd2FybmluZyBmaXgKPj4gaW4gc3RhYmxlIHRyZWUuCj4KPiBMZXQncyBzZWUg d2hpY2ggcGF0Y2hlcyB0aGF0IHdvdWxkIGJlLCBJIHRoaW5rIHRoaXMgaXMgdGhlIGZ1bGwgbGlz dCBvZgo+IG5vZGVzIHRoYXQgZ290IGFuIGV4dHJhICNwaHktY2VsbHM6Cj4KPiBjMjJmZTY5NjE1 N2QgQVJNOiBkdHM6IEZpeCBkbTgxNHggbWlzc2luZyBwaHktY2VsbHMgcHJvcGVydHkKPiBmMGUx MWZmOGZmNjUgQVJNOiBkdHM6IGFtMzN4eDogQWRkIG1pc3NpbmcgI3BoeS1jZWxscyB0byB0aSxh bTMzNXgtdXNiLXBoeQo+IGM1YmJmMzU4Yjc5MCBhcm06IGR0czogbnNwaXJlOiBBZGQgbWlzc2lu ZyAjcGh5LWNlbGxzIHRvIHVzYi1ub3AteGNlaXYKPiA0NGU1ZGNlZDJlZjYgYXJtOiBkdHM6IG1h cnZlbGw6IEFkZCBtaXNzaW5nICNwaHktY2VsbHMgdG8gdXNiLW5vcC14Y2Vpdgo+IDAxNGQ2ZGE2 Y2IyNSBBUk06IGR0czogYmNtMjgzeDogRml4IERUQyB3YXJuaW5ncyBhYm91dCBtaXNzaW5nIHBo eS1jZWxscwo+IGY1NjhmNmY1NTRiOCBBUk06IGR0czogb21hcDogQWRkIG1pc3NpbmcgI3BoeS1j ZWxscyB0byB1c2Itbm9wLXhjZWl2Cj4KPiBwbHVzIGEgY291cGxlIGluIGxpbnV4LW5leHQ6Cj4K PiBkNzQ1ZDVmMjc3YmYgQVJNOiBkdHM6IGlteDUxLXppaS1yZHUxOiBBZGQgbWlzc2luZyAjcGh5 LWNlbGxzIHRvIHVzYi1ub3AteGNlaXYKPiA5MTVmYmU1OWNiZjIgQVJNOiBkdHM6IGlteDogQWRk IG1pc3NpbmcgI3BoeS1jZWxscyB0byB1c2Itbm9wLXhjZWl2Cj4KPiBJdCdzIGEgbG90IG9mIHBh dGNoZXMgdG8gcmV2ZXJ0LCBhbmQgSSBndWVzcyBpdCB3b3VsZCBnZXQgdXMgYmFjayB0byBodW5k cmVkcwo+IG9mIHdhcm5pbmdzIGluIGFuIGFsbG1vZGNvbmZpZyBidWlsZCwgc28gSSdkIGZpcnN0 IHRyeSB0byBjb21lIHVwIHdpdGgKPiB3YXlzIHRvIHByb3ZlIHRoYXQgYXQgbGVhc3Qgc29tZSBv ZiB0aGVtIGNhbiBzdGF5Lgo+Cj4gQWxtb3N0IGFsbCB0aGUgd2FybmluZ3MgYXJlIGFib3V0ICJ1 c2Itbm9wLXhjZWl2IiBwaHlzLCB0aGUgb25seSBleGNlcHRpb25zCj4gSSBjb3VsZCBmaW5kIGFy ZSB0aGUgT01BUCBvbmVzICh0aGUgZmlyc3QgdHdvIHBhdGNoZXMpLCB3aGljaCB1c2UKPiAidGks YW0zMzV4LXVzYi1waHkiIGFuZCBhcmUgcmVmZXJlbmNlZCBmcm9tIGEgInRpLG11c2ItYW0zM3h4 Ii4gVGhhdAo+IHBhcnRpY3VsYXIgZHJpdmVyIGlzIG5vdCBhZmZlY3RlZCBieSB0aGUgYnVnLCBz byB3ZSBjYW4gbGVhdmUgdGhhdCBpbi4KPgo+IFRvIGRlYWwgd2l0aCBhbGwgdGhlICJ1c2Itbm9w LXhjZWl2IiAgcmVmZXJlbmNlcyBpbmNsdWRpbmcgdGhlIG9uZSB0aGF0Cj4gU3RlZmFuIHJlcG9y dGVkLCB3ZSBjb3VsZCB1c2UgYSBtdWNoIHNpbXBsZXIgdmVyc2lvbiBvZiBteSBlYXJsaWVyCj4g cGF0Y2gsIGRvIHlvdSB0aGluayB0aGlzIGlzIGFueSBiZXR0ZXI/Cj4KPiBTaWduZWQtb2ZmLWJ5 OiBBcm5kIEJlcmdtYW5uIDxhcm5kQGFybmRiLmRlPgo+Cj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMv cGh5L3BoeS1jb3JlLmMgYi9kcml2ZXJzL3BoeS9waHktY29yZS5jCj4gaW5kZXggYjQ5NjRiMDY3 YWVjLi5mMDU2ZDhmYjM5MjEgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVycy9waHkvcGh5LWNvcmUuYwo+ ICsrKyBiL2RyaXZlcnMvcGh5L3BoeS1jb3JlLmMKPiBAQCAtNDEwLDYgKzQxMCwxMCBAQCBzdGF0 aWMgc3RydWN0IHBoeSAqX29mX3BoeV9nZXQoc3RydWN0IGRldmljZV9ub2RlCj4gKm5wLCBpbnQg aW5kZXgpCj4gICAgICAgICBpZiAocmV0KQo+ICAgICAgICAgICAgICAgICByZXR1cm4gRVJSX1BU UigtRU5PREVWKTsKPgo+ICsgICAgICAgLyogVGhpcyBwaHkgdHlwZSBoYW5kbGVkIGJ5IHRoZSB1 c2ItcGh5IHN1YnN5c3RlbSBmb3Igbm93ICovCj4gKyAgICAgICBpZiAob2ZfZGV2aWNlX2lzX2Nv bXBhdGlibGUoInVzYi1ub3AteGNlaXYiKSkKPiArICAgICAgICAgICAgICAgcmV0dXJuIEVSUl9Q VFIoLUVOT0RFVik7Cj4gKwo+ICAgICAgICAgbXV0ZXhfbG9jaygmcGh5X3Byb3ZpZGVyX211dGV4 KTsKPiAgICAgICAgIHBoeV9wcm92aWRlciA9IG9mX3BoeV9wcm92aWRlcl9sb29rdXAoYXJncy5u cCk7Cj4gICAgICAgICBpZiAoSVNfRVJSKHBoeV9wcm92aWRlcikgfHwgIXRyeV9tb2R1bGVfZ2V0 KHBoeV9wcm92aWRlci0+b3duZXIpKSB7CgpUaGlzIHNlZW1zIGxpa2UgYSBuaWNlIHdvcmthcm91 bmQhCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: eric@anholt.net (Eric Anholt) Date: Thu, 11 Jan 2018 10:16:31 -0800 Subject: [PATCH] phy: work around 'phys' references to usb-phy devices In-Reply-To: References: <20180108130116.80148-1-arnd@arndb.de> <6dd37865-9c71-29f9-16b4-26e51e6b1c70@ti.com> Message-ID: <87d12guups.fsf@anholt.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Arnd Bergmann writes: > On Thu, Jan 11, 2018 at 2:30 PM, Kishon Vijay Abraham I wrote: >> On Thursday 11 January 2018 02:27 AM, Arnd Bergmann wrote: >>> On Mon, Jan 8, 2018 at 7:32 PM, Kishon Vijay Abraham I wrote: >>>> On Monday 08 January 2018 06:31 PM, Arnd Bergmann wrote: >>>>> Stefan Wahren reports a problem with a warning fix that was merged >>>>> --- >>>>> This obviously needs to be tested, I wrote this up as a reply to >>>>> Stefan's bug report. I'm fairly sure that I covered all usb-phy >>>>> driver strings here. My goal is to have a fix merged into 4.15 >>>>> rather than reverting all the DT fixes. >>>> >>>> Shouldn't the fix be in phy consumer drivers to not return error if it's able >>>> to find the phy either using usb-phy or generic phy? >>> >>> Stefan has posted a patch to that effect now, but I fear that might be >>> a little fragile, in particular this short before the release with the >>> regression >>> in place. >>> >>> The main problem is that we'd have to change the generic >>> usb_add_hcd() function in addition to dwc2 and dwc3 to ignore >>> -EPROBE_DEFER from phy_get() whenever usb_get_phy_dev() >>> has already succeeded. >>> >>> If there is any HCD that relies on usb_add_hcd() to get both the >>> usb_phy and the phy structures, and it may need to defer probing >>> when the latter one isn't ready yet, that fix would break another >>> driver. >> >> hmm.. IMO the better thing right now would be to revert the dt patch which adds >> #phy-cells. >> We have to see if there are better fixes in order to add #phy-cells warning fix >> in stable tree. > > Let's see which patches that would be, I think this is the full list of > nodes that got an extra #phy-cells: > > c22fe696157d ARM: dts: Fix dm814x missing phy-cells property > f0e11ff8ff65 ARM: dts: am33xx: Add missing #phy-cells to ti,am335x-usb-phy > c5bbf358b790 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv > 44e5dced2ef6 arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv > 014d6da6cb25 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells > f568f6f554b8 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv > > plus a couple in linux-next: > > d745d5f277bf ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv > 915fbe59cbf2 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv > > It's a lot of patches to revert, and I guess it would get us back to hundreds > of warnings in an allmodconfig build, so I'd first try to come up with > ways to prove that at least some of them can stay. > > Almost all the warnings are about "usb-nop-xceiv" phys, the only exceptions > I could find are the OMAP ones (the first two patches), which use > "ti,am335x-usb-phy" and are referenced from a "ti,musb-am33xx". That > particular driver is not affected by the bug, so we can leave that in. > > To deal with all the "usb-nop-xceiv" references including the one that > Stefan reported, we could use a much simpler version of my earlier > patch, do you think this is any better? > > Signed-off-by: Arnd Bergmann > > diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c > index b4964b067aec..f056d8fb3921 100644 > --- a/drivers/phy/phy-core.c > +++ b/drivers/phy/phy-core.c > @@ -410,6 +410,10 @@ static struct phy *_of_phy_get(struct device_node > *np, int index) > if (ret) > return ERR_PTR(-ENODEV); > > + /* This phy type handled by the usb-phy subsystem for now */ > + if (of_device_is_compatible("usb-nop-xceiv")) > + return ERR_PTR(-ENODEV); > + > mutex_lock(&phy_provider_mutex); > phy_provider = of_phy_provider_lookup(args.np); > if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) { This seems like a nice workaround! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH] phy: work around 'phys' references to usb-phy devices Date: Thu, 11 Jan 2018 10:16:31 -0800 Message-ID: <87d12guups.fsf@anholt.net> References: <20180108130116.80148-1-arnd@arndb.de> <6dd37865-9c71-29f9-16b4-26e51e6b1c70@ti.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Arnd Bergmann , Kishon Vijay Abraham I Cc: Florian Fainelli , DTML , Linux ARM , Rob Herring , linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "# 3.4.x" , Stefan Wahren , Felipe Balbi , Andrzej Pietrasiewicz , Linux Kernel Mailing List List-Id: devicetree@vger.kernel.org --=-=-= Content-Type: text/plain Arnd Bergmann writes: > On Thu, Jan 11, 2018 at 2:30 PM, Kishon Vijay Abraham I wrote: >> On Thursday 11 January 2018 02:27 AM, Arnd Bergmann wrote: >>> On Mon, Jan 8, 2018 at 7:32 PM, Kishon Vijay Abraham I wrote: >>>> On Monday 08 January 2018 06:31 PM, Arnd Bergmann wrote: >>>>> Stefan Wahren reports a problem with a warning fix that was merged >>>>> --- >>>>> This obviously needs to be tested, I wrote this up as a reply to >>>>> Stefan's bug report. I'm fairly sure that I covered all usb-phy >>>>> driver strings here. My goal is to have a fix merged into 4.15 >>>>> rather than reverting all the DT fixes. >>>> >>>> Shouldn't the fix be in phy consumer drivers to not return error if it's able >>>> to find the phy either using usb-phy or generic phy? >>> >>> Stefan has posted a patch to that effect now, but I fear that might be >>> a little fragile, in particular this short before the release with the >>> regression >>> in place. >>> >>> The main problem is that we'd have to change the generic >>> usb_add_hcd() function in addition to dwc2 and dwc3 to ignore >>> -EPROBE_DEFER from phy_get() whenever usb_get_phy_dev() >>> has already succeeded. >>> >>> If there is any HCD that relies on usb_add_hcd() to get both the >>> usb_phy and the phy structures, and it may need to defer probing >>> when the latter one isn't ready yet, that fix would break another >>> driver. >> >> hmm.. IMO the better thing right now would be to revert the dt patch which adds >> #phy-cells. >> We have to see if there are better fixes in order to add #phy-cells warning fix >> in stable tree. > > Let's see which patches that would be, I think this is the full list of > nodes that got an extra #phy-cells: > > c22fe696157d ARM: dts: Fix dm814x missing phy-cells property > f0e11ff8ff65 ARM: dts: am33xx: Add missing #phy-cells to ti,am335x-usb-phy > c5bbf358b790 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv > 44e5dced2ef6 arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv > 014d6da6cb25 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells > f568f6f554b8 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv > > plus a couple in linux-next: > > d745d5f277bf ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv > 915fbe59cbf2 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv > > It's a lot of patches to revert, and I guess it would get us back to hundreds > of warnings in an allmodconfig build, so I'd first try to come up with > ways to prove that at least some of them can stay. > > Almost all the warnings are about "usb-nop-xceiv" phys, the only exceptions > I could find are the OMAP ones (the first two patches), which use > "ti,am335x-usb-phy" and are referenced from a "ti,musb-am33xx". That > particular driver is not affected by the bug, so we can leave that in. > > To deal with all the "usb-nop-xceiv" references including the one that > Stefan reported, we could use a much simpler version of my earlier > patch, do you think this is any better? > > Signed-off-by: Arnd Bergmann > > diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c > index b4964b067aec..f056d8fb3921 100644 > --- a/drivers/phy/phy-core.c > +++ b/drivers/phy/phy-core.c > @@ -410,6 +410,10 @@ static struct phy *_of_phy_get(struct device_node > *np, int index) > if (ret) > return ERR_PTR(-ENODEV); > > + /* This phy type handled by the usb-phy subsystem for now */ > + if (of_device_is_compatible("usb-nop-xceiv")) > + return ERR_PTR(-ENODEV); > + > mutex_lock(&phy_provider_mutex); > phy_provider = of_phy_provider_lookup(args.np); > if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) { This seems like a nice workaround! --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlpXqf8ACgkQtdYpNtH8 nuilQw/+OUSXu526Rio/zESd4lqsIjm6T1nnwROIDX3LnIaXkYYekw9HDgCJhXMg G+Egu4Gs3URruG2WV9z23eoh5hZbxoVtNLhaHtvyavUP6X0YJiZ6/LpKpFzgGBXk xyt0dyHo5m1aNziIQQbEz5pSbWJdMqV/McMyN+7b/+RTbSbWeY7zW4GNBbKVVp/M nM6Uk5W6SLgLBn+unuktQgiTllCMXlWpyrDqYcsFhD6y4RLoZ+IUwXcxT0Fn6le6 DSpo3S1hRA+blgjFN3bo5CtrnY+baXmGEjyZ27HB5tXRhRr52utdWhqNgtz0A6lu opiYz8wEzkhsh3o/GE95nhYddQoFMS7qod966TZJV1S1x3H+AMuA2U/07YXTz6Tc v2y5lQK4sKHMAJoFoFqR3JNMQShPpFey5YiDay5lpMvpz7fHTZSIte9OW9SJQ06E bs7WEqu+dULnYLHPiEGD3cDROCfxeTtB4MqZJ1hTGNCJlEaQsVU9KyG3kC0jGAVS aSx34bPkwlSsExsH9cdqtNl0Waq/D35XwHTZuGGabCqQ56+bsO6pbM0a/OAilOJS cqdUjE0znjm7+2lvtPLVrUaiB9FJKljuC6i6f87JgXqH8Vyw4cht1EWw8IixkcuT gTxcL+FOdwjW9FfPWJJvwgm6uLMPQEITvnznk9GTccM3vBLcb3U= =E2a8 -----END PGP SIGNATURE----- --=-=-=-- -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935188AbeAKSQi (ORCPT + 1 other); Thu, 11 Jan 2018 13:16:38 -0500 Received: from anholt.net ([50.246.234.109]:45110 "EHLO anholt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934482AbeAKSQg (ORCPT ); Thu, 11 Jan 2018 13:16:36 -0500 From: Eric Anholt To: Arnd Bergmann , Kishon Vijay Abraham I Cc: Florian Fainelli , DTML , Linux ARM , Rob Herring , linux-usb@vger.kernel.org, "# 3.4.x" , Stefan Wahren , Felipe Balbi , Andrzej Pietrasiewicz , Linux Kernel Mailing List Subject: Re: [PATCH] phy: work around 'phys' references to usb-phy devices In-Reply-To: References: <20180108130116.80148-1-arnd@arndb.de> <6dd37865-9c71-29f9-16b4-26e51e6b1c70@ti.com> User-Agent: Notmuch/0.22.2+1~gb0bcfaa (http://notmuchmail.org) Emacs/25.2.2 (x86_64-pc-linux-gnu) Date: Thu, 11 Jan 2018 10:16:31 -0800 Message-ID: <87d12guups.fsf@anholt.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: --=-=-= Content-Type: text/plain Arnd Bergmann writes: > On Thu, Jan 11, 2018 at 2:30 PM, Kishon Vijay Abraham I wrote: >> On Thursday 11 January 2018 02:27 AM, Arnd Bergmann wrote: >>> On Mon, Jan 8, 2018 at 7:32 PM, Kishon Vijay Abraham I wrote: >>>> On Monday 08 January 2018 06:31 PM, Arnd Bergmann wrote: >>>>> Stefan Wahren reports a problem with a warning fix that was merged >>>>> --- >>>>> This obviously needs to be tested, I wrote this up as a reply to >>>>> Stefan's bug report. I'm fairly sure that I covered all usb-phy >>>>> driver strings here. My goal is to have a fix merged into 4.15 >>>>> rather than reverting all the DT fixes. >>>> >>>> Shouldn't the fix be in phy consumer drivers to not return error if it's able >>>> to find the phy either using usb-phy or generic phy? >>> >>> Stefan has posted a patch to that effect now, but I fear that might be >>> a little fragile, in particular this short before the release with the >>> regression >>> in place. >>> >>> The main problem is that we'd have to change the generic >>> usb_add_hcd() function in addition to dwc2 and dwc3 to ignore >>> -EPROBE_DEFER from phy_get() whenever usb_get_phy_dev() >>> has already succeeded. >>> >>> If there is any HCD that relies on usb_add_hcd() to get both the >>> usb_phy and the phy structures, and it may need to defer probing >>> when the latter one isn't ready yet, that fix would break another >>> driver. >> >> hmm.. IMO the better thing right now would be to revert the dt patch which adds >> #phy-cells. >> We have to see if there are better fixes in order to add #phy-cells warning fix >> in stable tree. > > Let's see which patches that would be, I think this is the full list of > nodes that got an extra #phy-cells: > > c22fe696157d ARM: dts: Fix dm814x missing phy-cells property > f0e11ff8ff65 ARM: dts: am33xx: Add missing #phy-cells to ti,am335x-usb-phy > c5bbf358b790 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv > 44e5dced2ef6 arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv > 014d6da6cb25 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells > f568f6f554b8 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv > > plus a couple in linux-next: > > d745d5f277bf ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv > 915fbe59cbf2 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv > > It's a lot of patches to revert, and I guess it would get us back to hundreds > of warnings in an allmodconfig build, so I'd first try to come up with > ways to prove that at least some of them can stay. > > Almost all the warnings are about "usb-nop-xceiv" phys, the only exceptions > I could find are the OMAP ones (the first two patches), which use > "ti,am335x-usb-phy" and are referenced from a "ti,musb-am33xx". That > particular driver is not affected by the bug, so we can leave that in. > > To deal with all the "usb-nop-xceiv" references including the one that > Stefan reported, we could use a much simpler version of my earlier > patch, do you think this is any better? > > Signed-off-by: Arnd Bergmann > > diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c > index b4964b067aec..f056d8fb3921 100644 > --- a/drivers/phy/phy-core.c > +++ b/drivers/phy/phy-core.c > @@ -410,6 +410,10 @@ static struct phy *_of_phy_get(struct device_node > *np, int index) > if (ret) > return ERR_PTR(-ENODEV); > > + /* This phy type handled by the usb-phy subsystem for now */ > + if (of_device_is_compatible("usb-nop-xceiv")) > + return ERR_PTR(-ENODEV); > + > mutex_lock(&phy_provider_mutex); > phy_provider = of_phy_provider_lookup(args.np); > if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) { This seems like a nice workaround! --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlpXqf8ACgkQtdYpNtH8 nuilQw/+OUSXu526Rio/zESd4lqsIjm6T1nnwROIDX3LnIaXkYYekw9HDgCJhXMg G+Egu4Gs3URruG2WV9z23eoh5hZbxoVtNLhaHtvyavUP6X0YJiZ6/LpKpFzgGBXk xyt0dyHo5m1aNziIQQbEz5pSbWJdMqV/McMyN+7b/+RTbSbWeY7zW4GNBbKVVp/M nM6Uk5W6SLgLBn+unuktQgiTllCMXlWpyrDqYcsFhD6y4RLoZ+IUwXcxT0Fn6le6 DSpo3S1hRA+blgjFN3bo5CtrnY+baXmGEjyZ27HB5tXRhRr52utdWhqNgtz0A6lu opiYz8wEzkhsh3o/GE95nhYddQoFMS7qod966TZJV1S1x3H+AMuA2U/07YXTz6Tc v2y5lQK4sKHMAJoFoFqR3JNMQShPpFey5YiDay5lpMvpz7fHTZSIte9OW9SJQ06E bs7WEqu+dULnYLHPiEGD3cDROCfxeTtB4MqZJ1hTGNCJlEaQsVU9KyG3kC0jGAVS aSx34bPkwlSsExsH9cdqtNl0Waq/D35XwHTZuGGabCqQ56+bsO6pbM0a/OAilOJS cqdUjE0znjm7+2lvtPLVrUaiB9FJKljuC6i6f87JgXqH8Vyw4cht1EWw8IixkcuT gTxcL+FOdwjW9FfPWJJvwgm6uLMPQEITvnznk9GTccM3vBLcb3U= =E2a8 -----END PGP SIGNATURE----- --=-=-=--