ret = devm_gpio_request_one(&pdev->dev, gpio, flags,
"minnow_phy_reset");
if (ret) {
dev_err(&pdev->dev,
"ERR: Can't request PHY reset GPIO line '%d'\n", gpio);
But deliberately does not about the probe because there is a chance
things will work just fine. If they do not, the PHY detection code will
print display errors about a failure to communicate over RGMII, and the
device probe will fail from there.
This still seems like the correct approach to me. Does anyone disagree?
Considering this scenario it seems to be correct. But if
devm_gpio_request_one() may fail for "unfriendly" reasons too, then
it's incomplete.
(we still need to sort out the GPIOLIB and GPIO_SCH dependency though of
course)
Maybe if GPIOLIB has the static inline stubs returning -ENODEV we could
use a patch similar to the one attached here.
I think you may have inverted your logic on the return?
+ dev_warn(&pdev->dev,
+ "ERR: Can't request PHY reset GPIO line '%d'\n", gpio);
+ return ret == -ENODEV ? ret : 0;
Did you mean:
+ /*
* Things may still work if the GPIO driver wasn't
* compiled in
*/
Actually I did mean what I sent, but I misunderstood the above case
where it may work without GPIO driver.
But anyway, "things *may* still work" IMO may create instability issue
by allowing an uncertain situation to go through. If PCH_GBE depends on
GPIOLIB in MinnowBoard case it should fail right away with a clear
message why.
If pch_gbe driver can detect what devm_gpio_request_one() returns from
the static inline stub then it can create a condition to gracefully
fail. So whoever is interested in MinnowBoard will spend less time
trying to identify this problem.
Br, David Cohen
+ return ret == -ENODEV ? 0 : ret;
The concern here of course would be someone added another GPIO
controller over i2c over the expansion connector or something similar
and did not enable the GPIO_SCH driver, then it could conceivably grab
the wrong GPIO pin.... or would those never map to GPIO 13?
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
