netdev - Re: [gpio:for-next 67/67] pch_gbe_main.c:undefined reference to `devm_gpio_request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Oct 2013 11:01:41 -0700
From:	David Cohen <david.a.cohen@...ux.intel.com>
To:	Darren Hart <dvhart@...ux.intel.com>
CC:	Linus Walleij <linus.walleij@...aro.org>,
	"David S. Miller" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Fengguang Wu <fengguang.wu@...el.com>,
	Alexandre Courbot <acourbot@...dia.com>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>
Subject: Re: [gpio:for-next 67/67] pch_gbe_main.c:undefined reference to `devm_gpio_request_one'

>>> 	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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html