[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkda7J0USKq4NLQgJkyGXVttAHQyOvD2p2xsDT=v9fX+BvA@mail.gmail.com>
Date: Fri, 27 Mar 2015 11:24:45 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: Alexandre Courbot <gnurou@...il.com>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Johan Hovold <johan@...nel.org>
Subject: Re: [PATCH] gpio: gpio-tb10x: remove incorrect __exit markup
On Wed, Mar 25, 2015 at 6:14 PM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
> On Wed, Mar 25, 2015 at 04:32:13PM +0100, Linus Walleij wrote:
>> For a bool driver of this type (typically compiled in and probed
>> at boot) that makes most sense to me.
>
> Hmm, I do not think this is a good justification for disabling
> unbinding. However, as far as I can see, removing gpiochip will succeed
> even though there are users of gpios in the system and that might
> justify the change. But does this mean that we give up on making
> gpiochip clean up properly and we should schedule gpiochip_remove() and
> the rest of gpio cleanup infrastructure for removal and declare that
> gpio drivers can not ever be made modules?
No. Johan Hovold is looking into use cases for GPIO chips that come
and go, think GPIO on USB. These obviously need remove() semantics.
What I'm thinking is that the SoC-embedded GPIO controllers (I don't know
how many these are) should probably be bool in Kconfig and also
patched not to have remove() functions and drop the sysfs attribs
for unbinding.
But now I think I'll just apply the patch anyways because it sure does
not make a difference wrt to the bigger problem, so I'm just bitching
around about details and thinking aloud, sorry..
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