Hello, On Wed, 16 Jan 2019 14:30:28 +0100, Paul Kocialkowski wrote: > > Why is this conditional on the generic PHY lookup failing? > > > > Don't we simply want: > > > > ci->phy = devm_phy_get(dev->parent, "usb-phy"); > > ci->usb_phy = devm_usb_get_phy_by_phandle(dev->parent, "phys", 0); > > if (IS_ERR(ci->usb_phy)) > > ci->usb_phy = devm_usb_get_phy(dev->parent, USB_PHY_TYPE_USB2); > > > > ? > > Well, the code dealing with the PHY later on will use ci->phy over ci- > >usb_phy (so generic PHY API first). As a result, if the > devm_usb_get_phy_by_phandle lookup fails but we got a generic PHY, the > latter will be used and there is no need for a fallback. That's why I > put both conditions there. Maybe that's too much of an assumption? Well prior to your code, there was already a possibility for both ci->phy and ci->usb_phy to be valid. I don't think it's really useful to avoid the fallback when a generic PHY has already been found, it's confusing. If really you want to clarify that, it should be: /* Let's first try to find a generic PHY */ ci->phy = devm_phy_get(dev->parent, "usb-phy"); if (IS_ERR(ci->phy)) { /* Fall back to legacy USB PHY */ ci->usb_phy = devm_usb_get_phy_by_phandle(dev->parent, "phys", 0); if (IS_ERR(ci->usb_phy)) ci->usb_phy = devm_usb_get_phy(dev->parent, USB_PHY_TYPE_USB2); } With that, you would only have either ci->phy or ci->usb_phy be valid, and never both. With your change, you can have ci->phy and ci->usb_phy both be valid if the legacy USB PHY was found using devm_usb_get_phy_by_phandle(), but not if we fell back to devm_usb_get_phy(). > > Does this needs a "Fixes:" tag ? It's not fixing a regression because > > nobody complained until now, but it's really fixing a behavior that > > wasn't correct. > > Yes I it this makes sense to consider that this was incorrect behavior > starting from the moment the dt bindings were formalized for the > driver, which would be commit d7d30c911dd957e274c3da6910d4286862ab1d78. > > Do you think that would nake sense? Up to the maintainer I'd say. I don't have any preference here. Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com