From: Tejun Heo <tj@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Stephen Warren <swarren@wwwdotorg.org>,
linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] resource: Add device-managed request/release_resource()
Date: Tue, 22 Jul 2014 15:01:20 -0400 [thread overview]
Message-ID: <20140722190120.GM13851@htj.dyndns.org> (raw)
In-Reply-To: <20140722185002.GC19181@google.com>
Hello,
On Tue, Jul 22, 2014 at 12:50:02PM -0600, Bjorn Helgaas wrote:
> [+cc Tejun, LKML]
>
> On Fri, Jul 11, 2014 at 09:08:24AM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Provide device-managed implementations of the request_resource() and
> > release_resource() functions. Upon failure to request a resource, the
> > new devm_request_resource() function will output an error message for
> > consistent error reporting.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> This seems OK to me, but I don't consider myself a devres maintainer. I
> added Tejun and LKML for any comment. Minor nit below.
If there are gonna be users of the interface, sure.
> > +int devm_request_resource(struct device *dev, struct resource *root,
> > + struct resource *new)
> > +{
> > + struct resource *conflict, **ptr;
> > +
> > + ptr = devres_alloc(devm_resource_release, sizeof(*ptr), GFP_KERNEL);
> > + if (!ptr)
> > + return -ENOMEM;
> > +
> > + *ptr = new;
> > +
> > + conflict = request_resource_conflict(root, new);
> > + if (!conflict) {
> > + devres_add(dev, ptr);
> > + return 0;
> > + }
> > +
> > + dev_err(dev, "resource collision: %pR conflicts with %s %pR\n", new,
> > + conflict->name, conflict);
> > + devres_free(ptr);
> > + return -EBUSY;
>
> Personally I would write this as:
>
> conflict = request_resource_conflict(...);
> if (conflict) {
> dev_err(...);
> devres_free(...);
> return -EBUSY;
> }
>
> devres_add(...);
> return 0;
>
> so the straight-line path is the normal, non-error path and errors are
> detected and dealt with in the "if" bodies. Right now the "if" bodies
> are a mix of error handling and normal path. But that's just my personal
> preference.
Agreed.
> > +static int devm_resource_match(struct device *dev, void *res, void *data)
> > +{
> > + struct resource **ptr = res;
> > +
> > + if (WARN_ON(!ptr || !*ptr))
> > + return 0;
How would !ptr or !*ptr possibly happen? Wouldn't that be a bug
already?
Thanks.
--
tejun
next prev parent reply other threads:[~2014-07-22 19:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1405062505-2606-1-git-send-email-thierry.reding@gmail.com>
2014-07-22 18:50 ` Bjorn Helgaas
2014-07-22 19:01 ` Tejun Heo [this message]
2014-07-29 11:33 ` Thierry Reding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140722190120.GM13851@htj.dyndns.org \
--to=tj@kernel.org \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®