[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdaxxn9nWKjFF=XD5F2kus69-8uxqPWA1vt1RJ0aGJ-Mvw@mail.gmail.com>
Date: Mon, 11 Feb 2013 14:53:47 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Grant Likely <grant.likely@...retlab.ca>
Cc: Viresh Kumar <viresh.kumar@...aro.org>,
Thierry Reding <thierry.reding@...onic-design.de>,
linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Arnd Bergmann <arnd@...db.de>,
Wolfram Sang <w.sang@...gutronix.de>,
Russell King - ARM Linux <linux@....linux.org.uk>
Subject: Re: [PATCH 08/33] gpio: Convert to devm_ioremap_resource()
On Sat, Feb 9, 2013 at 2:52 PM, Grant Likely <grant.likely@...retlab.ca> wrote:
> On Mon, 21 Jan 2013 16:22:21 +0530, Viresh Kumar <viresh.kumar@...aro.org> wrote:
>> > - spics->base = devm_request_and_ioremap(&pdev->dev, res);
>> > - if (!spics->base) {
>> > - dev_err(&pdev->dev, "request and ioremap fail\n");
>>
>> can we keep it as is?
>
> And this is why I dislike the ERR_PTR pattern so much. It goes against
> every instinct about what is and is not a valid pointer.
>
> I know people want error codes, but I think hoping that all users will
> remember to do 'if (IS_ERR(ptr))' instead of 'if (!ptr)' makes things
> worse not better.
NB: among the error codes people want to propagate from
consumer interfaces such as say, clk_get(), regulator_get()
and pinctrl_get() is -EPROBE_DEFER. So just "something
failed" (return NULL) isn't enough.
We then obviously need to return an int as error code instead
and pass the pointer as argument, so do you mean we should
refactor all the *_get() things from e.g.:
struct clk *clk_get(struct device *dev, const char *id);
into something like:
int clk_get(struct clk **clk, struct device *dev, const char *id);
across the entire kernel?
Yours,
Linus Walleij
--
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/
Powered by blists - more mailing lists