Re: [PATCH v7 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver.

[Yunzhi Li <lyz@rock-chips.com>]

Hi paul:

在 2015/1/9 10:15, Paul Zimmerman 写道:
>> [...]
>>   	/*
>> -	 * Attempt to find a generic PHY, then look for an old style
>> -	 * USB PHY, finally fall back to pdata
>> +	 * If platform probe couldn't find a generic PHY or an old style
>> +	 * USB PHY, fall back to pdata
>>   	 */
>> -	phy = devm_phy_get(dev, "usb2-phy");
>> -	if (IS_ERR(phy)) {
>> -		uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
>> -		if (IS_ERR(uphy)) {
>> -			/* Fallback for pdata */
>> -			plat = dev_get_platdata(dev);
>> -			if (!plat) {
>> -				dev_err(dev,
>> -				"no platform data or transceiver defined\n");
>> -				return -EPROBE_DEFER;
>> -			}
>> -			hsotg->plat = plat;
>> -		} else
>> -			hsotg->uphy = uphy;
>> -	} else {
>> -		hsotg->phy = phy;
>> +	if (IS_ERR_OR_NULL(hsotg->phy) && IS_ERR_OR_NULL(hsotg->uphy)) {
>> +		plat = dev_get_platdata(dev);
>> +		if (!plat) {
>> +			dev_err(dev,
>> +			"no platform data or transceiver defined\n");
>> +			return -EPROBE_DEFER;
> Hi Yunzhi,
>
> Testing Felipe's testing/next branch on an Altera SOCFPGA platform,
> the driver never loads because it always returns -EPROBE_DEFER here.
> Apparently the SOCFPGA platform does not have any platform data
> defined, because dev_get_platdata() always returns NULL.
>
> If I remove the -EPROBE_DEFER return and have it continue on, the
> driver works. Reverting the patch also makes it work.
     When I debug this problem, I checked socfpga.dtsi, there is a 
usbphy node defined for each
dwc2 controller, so I think when running dwc2_driver_probe() uphy = 
devm_usb_get_phy()
should get a valid usbphy pointer and hsotg->uphy will not be NULL or 
ERROR, then in dwc2_gadget_init()
it will not return -EPROBE_DEFER. I have no idea about why you meet  
-EPROBE_DEFER, could you please tell
me what's the return value of devm_usb_get_phy() on your socfpga board ?

> I am testing with the driver built-in. I haven't tried it as a module
> yet.
>
> Any ideas? Is the -EPROBE_DEFER return really needed here?
>