linux-kernel - Re: [PATCH v2 1/2] pinctrl: add pinctrl_provide

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:	Wed, 25 Apr 2012 17:49:36 +0800
From:	Dong Aisheng <aisheng.dong@...escale.com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	Dong Aisheng-B29396 <B29396@...escale.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>
Subject: Re: [PATCH v2 1/2] pinctrl: add pinctrl_provide_dummies interface
 for platforms to use

On Wed, Apr 25, 2012 at 03:00:23AM +0800, Stephen Warren wrote:
> On 04/24/2012 03:33 AM, Dong Aisheng wrote:
> > From: Dong Aisheng <dong.aisheng@...aro.org>
> > 
> > Add a interface pinctrl_provide_dummies for platform to indicate
> > whether it needs use pinctrl dummy state and dummy gpio.
> 
> > @@ -382,7 +396,12 @@ int pinctrl_request_gpio(unsigned gpio)
> >  	ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
> >  	if (ret) {
> >  		mutex_unlock(&pinctrl_mutex);
> > -		return -EINVAL;
> > +		if (pinctrl_dummy_gpio) {
> > +			pr_debug("pinctrl: using dummy gpio(%u)\n", gpio);
> > +			return 0;
> > +		} else {
> > +			return -EINVAL;
> > +		}
> >  	}
> 
> The only thing that should be calling pinctrl_request_gpio() is a GPIO
> driver. It should only be calling it for the GPIOs it manages. I'd
> expect that if a platform's pinctrl driver was not yet written to
> support the GPIO functionality, then the GPIO driver would not be
> calling this function.
> 
Hmm, pinctrl gpio is in the same situation as pinctrl state that gpio
driver may be shared between several platforms, with pinctrl support
or not.

> As such, I'm not sure that this part of the change is necessary.
> 
> If it is, then surely all the other pinctrl GPIO APIs need a similar change?
> 
Yes, i missed it, will fix.
Thanks for reminder.

> Finally, how does this interact with deferred probe: How does the code
> know whether the pinctrl driver and/or GPIO range is simply not yet
> registered, or whether it never will be? That'd be the difference
> between returning -EPROBE_DEFER or 0 in the if block above.
> 
Yes, it is an issue.
I don't have any good idea to distinguish them.
It seems regulator has the same issue.
What regulator does is if dummy regulator is used, use dummy gpio instead
regardless of defer probe.
I guess we may use the same way as regulator for pinctrl.
User can decide if using dummy gpio or defer probe since based on their
driver support.

The rule may be if your pinctrl driver supports gpio, then you should not use
dummy gpio. Then the dummy gpio support will not affect the defer probe.

> 
> I'm fine with the other parts of this patch.

Regards
Dong Aisheng

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/