linux-kernel - Re: [PATCH] regulator: fixed: support deferred probe for DT GPIOs

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] [day] [month] [year] [list]

Date:	Sat, 30 Jun 2012 12:48:58 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Liam Girdwood <lrg@...com>, linux-kernel@...r.kernel.org,
	Stephen Warren <swarren@...dia.com>
Subject: Re: [PATCH] regulator: fixed: support deferred probe for DT GPIOs

On Fri, Jun 29, 2012 at 09:30:51AM -0600, Stephen Warren wrote:

> I did consider making of_get_fixed_voltage_config() return a result
> code, but then it needs some other way of returning the pointer, so
> that seemed just as convoluted. Oh, I suppose it could use ERR_PTR()
> to do that; that'd be nice and simple. Would that do?

Meh, or just have the caller pass in the platform data rather than
allocate it in the function.

> Re: gpiolib doing it: How is that possible? of_get_named_gpio()
> certainly can return -EPROBE_DEFER, but the caller would still need to
> check it. The ideal case might be to just do:

> ret = gpio_request(of_get_named_gpio(...));
> if (ret)
>     return ret;

> and have gpio_request pass -EPROBE_DEFER from input to output.

Even better just have gpio_request() just return -EPROBE_DEFER instead
of -ENODEV.  There is no sane case where you'd request a GPIO you didn't
have a reasonable idea was going to be registered at some point (or
could be with appropriate system configuration) so we should just assume
that might happen.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)