Doesn't add much to the discussion. In the example I gave, the driver
already does synchronous probing. If the device can't probe
successfully because a supplier isn't ready, it doesn't matter if it's
a synchronous probe. The probe would still be deferred and we'll hit
the same issue. Even in the situation the commit [5] describes, if
parallelized probing is done and the PHY depended on something (say a
clock), you'd still end up not probing the PHY even if the driver is
present and the generic PHY would end up force probing it.

genphy is meant to be used when there is no other driver available.
It is a best effort, better than nothing, might work. And quite a few
boards rely on it. However, it should not be used when there is a
specific driver.

So if the PHY device has been probed, and -EPROBE_DEFER was returned,
we also need to return -EPROBE_DEFER here when deciding if genphy
should be used. It should then all unwind and try again later.

I don't know the device core, but it looks like dev->can_match tells
us what we need to know. If true, we know there is a driver for this
device. But i'm hesitant to make use of this outside of driver/base.

	Andrew