Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756870Ab0KJVPr (ORCPT ); Wed, 10 Nov 2010 16:15:47 -0500 Received: from mail-yx0-f174.google.com ([209.85.213.174]:45792 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756484Ab0KJVPq (ORCPT ); Wed, 10 Nov 2010 16:15:46 -0500 Date: Wed, 10 Nov 2010 14:15:40 -0700 From: Grant Likely To: Thomas Gleixner Cc: Maciej Szmigiero , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Anton Vorontsov , Greg Kroah-Hartman , Uwe Kleine-K?nig , Andrew Morton , Arnd Bergmann , Jonathan Cameron , Ben Nizette Subject: Re: [GPIO]implement sleeping GPIO chip removal Message-ID: <20101110211540.GA7063@angua.secretlab.ca> References: <4CD6F049.10102@o2.pl> <20101110050947.GC4110@angua.secretlab.ca> <4CDABA03.2050000@o2.pl> <4CDB0834.4080101@o2.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1456 Lines: 40 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/