On Wed, Nov 10, 2010 at 02:15:40PM -0700, Grant Likely wrote: > 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. Only use a kobject if you want to be in the sysfs hierarchy (which I don't think you want to do here.) If you want proper reference counting, use a 'struct kref' instead. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
