linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: ext Tony Lindgren <tony@atomide.com>,
	Haojian Zhuang <haojian.zhuang@linaro.org>,
	Linus Walleij <linus.walleij@stericsson.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Stephen Warren <swarren@nvidia.com>,
	Anmar Oueja <anmar.oueja@linaro.org>
Subject: Re: [PATCH] pinctrl: sink pinctrldev_list_mutex
Date: Fri, 24 May 2013 09:45:06 -0600	[thread overview]
Message-ID: <519F8B02.1080000@wwwdotorg.org> (raw)
In-Reply-To: <CACRpkdZieCmFnHCGUkv8EqcAtb3DA7dSZpimSdB4P81tZPJRoQ@mail.gmail.com>

On 05/24/2013 02:04 AM, Linus Walleij wrote:
> On Mon, May 20, 2013 at 10:40 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> 
>> This seems fine on the surface, but I do have one question:
>>
>> I think the pinctrl lock serves a couple of purposes:
>>
>> 1) Basic protection for accesses to the pinctrldev_list itself.
>>
>> This patch seems just fine w.r.t. this point.
>>
>> 2) Preventing pinctrl drivers from being unregistered (and their modules
>> unloaded) when some operation is being performed on/to them.
> 
> Prevention of module unloading of pin controllers has never
> been working properly, as there is no way to release the
> pinctrl handles taken by different drivers.
> 
> I think that is why most pin controller drivers are bool rather
> than tristate.

Once we get to multi-platform distro kernels, we will probably want all
the pinctrl drivers to be modules so only the correct one gets loaded
from an initrd. Hence, we'll want to move things to tristate rather than
away from it.

If we know the pinctrl subsystem doesn't yet work correctly with module
unloads, should we modify pinctrl_register() to simply take a lock on
the driver module and never drop it, so that we guarantee we don't try
to unload the module later? Or, is this effectively already in place?

In other words, I can accept that we know that we can't unload pinctrl
drivers, but given that, I think the kernel should make sure the user
/actually/ can't unload them.

  reply	other threads:[~2013-05-24 15:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-16  7:48 [PATCH] pinctrl: sink pinctrldev_list_mutex Linus Walleij
2013-05-20 20:40 ` Stephen Warren
2013-05-24  8:04   ` Linus Walleij
2013-05-24 15:45     ` Stephen Warren [this message]
2013-05-25  9:09       ` Linus Walleij
2013-05-28 15:14         ` Stephen Warren
2013-05-29 16:28           ` Linus Walleij

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=519F8B02.1080000@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=anmar.oueja@linaro.org \
    --cc=haojian.zhuang@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=swarren@nvidia.com \
    --cc=tony@atomide.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;
as well as URLs for NNTP newsgroup(s).