All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Maciej Szmigiero <mhej@o2.pl>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	Anton Vorontsov <avorontsov@ru.mvista.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>, Jonathan Cameron <jic23@cam.ac.uk>,
	Ben Nizette <bn@niasdigital.com>
Subject: Re: [GPIO]implement sleeping GPIO chip removal
Date: Wed, 10 Nov 2010 14:15:40 -0700	[thread overview]
Message-ID: <20101110211540.GA7063@angua.secretlab.ca> (raw)
In-Reply-To: <alpine.LFD.2.00.1011102203500.2900@localhost6.localdomain6>

On Wed, Nov 10, 2010 at 10:07:05PM +0100, Thomas Gleixner wrote:
> Can you please use a mail client which does proper line breaks at 78 ?
> 
> On Wed, 10 Nov 2010, Maciej Szmigiero wrote:
> > You misunderstood me.
> 
> No, I didnt.
> 
> > By "looping in hope that somebody will finally release the chip" I
> > meant the only real way to handle a GPIO chip unplugging in the
> > current kernel.  Which is way worse that preventing new requests,
> > then waiting for existing one to be released.  And this is exactly
> > what my patch does.
> 
> That still does not make it a good solution.
> 
> > I understand that it could be simplified by removing redundant code
> > (as Grant Likely had suggested before), and moving it to completion
> > interface instead of manipulating a task structure directly, but
> > this doesn't mean that the whole GPIO code has to be rewritten just
> > to add one functionality.
> 
> It's not about rewriting, it's about fixing the problem in the right
> way and not just hacking around it.
> 
> If we see a shortcoming like this, we fix it and do not magically work
> around it.

+1

Thomas is right.  kobject reference counting is the correct solution.
Nack on this approach.

g.

  reply	other threads:[~2010-11-10 21:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-07 18:30 [GPIO]implement sleeping GPIO chip removal Maciej Szmigiero
2010-11-10  5:09 ` Grant Likely
2010-11-10  9:49   ` Thomas Gleixner
2010-11-10 15:28   ` Maciej Szmigiero
2010-11-10 20:42     ` Thomas Gleixner
2010-11-10 21:01       ` Maciej Szmigiero
2010-11-10 21:07         ` Thomas Gleixner
2010-11-10 21:15           ` Grant Likely [this message]
2010-11-10 22:45             ` Greg KH
2010-11-10 22:47               ` Thomas Gleixner
2010-11-10 23:15               ` Paul Mundt
2010-11-10 22:14         ` Grant Likely
2010-11-12 20:46           ` Maciej Szmigiero

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=20101110211540.GA7063@angua.secretlab.ca \
    --to=grant.likely@secretlab.ca \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=avorontsov@ru.mvista.com \
    --cc=bn@niasdigital.com \
    --cc=gregkh@suse.de \
    --cc=jic23@cam.ac.uk \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhej@o2.pl \
    --cc=tglx@linutronix.de \
    --cc=u.kleine-koenig@pengutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.