linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Toshi Kani <toshi.kani@hpe.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@suse.de>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2-UPDATE2 3/4] resource: Add device-managed insert/remove_resource()
Date: Tue, 08 Mar 2016 18:00:33 -0700	[thread overview]
Message-ID: <1457485233.15454.530.camel@hpe.com> (raw)
In-Reply-To: <CA+55aFxJqjvsSz7eeobViGShoJV=FSx9gDbxK_L0WvSnh3xa3w@mail.gmail.com>

On Tue, 2016-03-08 at 15:31 -0800, Linus Torvalds wrote:
> On Tue, Mar 8, 2016 at 4:04 PM, Toshi Kani <toshi.kani@hpe.com> wrote:
> > 
> > Yes, I prefer the devm semantics.  insert_resource() and
> > remove_resource() are not exported interfaces.  So, with
> > devm_add_action(), we still need to introduce built-in exported
> > wrappers for insert/remove_resource(), unless we change to export them
> > directly.  Since we need to export "something", I think it is better to
> > export their devm interfaces.
> 
> So I'm coming from the background that
> 
>  (a) less code is better
> 
>  (b) the "devm_" interface may be convenient, but it has also
> traditionally also been a cause of problems and limitations.
> 
> Now, the main problems with the devm interface has been either
> ordering (which just isn't an issue with resource allocation - it's
> been an issue with irqs) or the fact that it can't always be used if
> you're not in the right context. So it's "convenient but potentially
> inflexible".
> 
> And the thing is, I think convenience functions mainly make sense for
> places where there are multiple users. If there really is just one or
> two (number completely pulled out of my ass), I don't see the point of
> a "convenience" function, when we've had the main actual _code_
> functionality for over a decade.
> 
> So unless there are more users, I'd suggest just exporting the
> insert_resource function.
> 
> We already export allocate_resource and adjust_resource.
> 
> Now, the _one_ argument for devm_insert_resource() is that we do have
> "devm_request_resource()".
> 
> But quite frankly, just counting the number of devm_request_resource()
> calls weakens that argument. There's 7 callers in the whole kernel.
> The regular "request_resource()" has 200+ callers.
> 
> That may be due to historical reasons, but it may also be at least
> partially due to (b) above - there are a number of cases where the
> "devm_xyz()" model doesn't work well.
> 
> So I think we should see the "devm_xyz()" forms as being a "let's make
> things easy for driver writers". I do _not_ think it makes sense for
> one-off users.
> 
> Now, if it turns out that there are lots of other potential users of
> devm_insert_resource(), that would maks all of my arguments go away.

I agree that there won't be many users of devm_insert_resource().  So, I am
going to export insert_resource() and remove_resource() as you suggested,
and let the NFIT driver to call them using devm_add_action() as a one-off
solution.

Thanks!
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2016-03-09  0:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-08 18:08 [PATCH v2-UPDATE2 3/4] resource: Add device-managed insert/remove_resource() Toshi Kani
2016-03-08 17:33 ` Ingo Molnar
2016-03-08 20:05 ` Linus Torvalds
2016-03-08 20:59   ` Dan Williams
2016-03-08 22:23     ` Linus Torvalds
2016-03-08 22:44       ` Dan Williams
2016-03-09  0:04         ` Toshi Kani
2016-03-08 23:31           ` Linus Torvalds
2016-03-09  1:00             ` Toshi Kani [this message]

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=1457485233.15454.530.camel@hpe.com \
    --to=toshi.kani@hpe.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@suse.de \
    --cc=dan.j.williams@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=mingo@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=torvalds@linux-foundation.org \
    /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;
as well as URLs for NNTP newsgroup(s).