Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759465AbYC0KVa (ORCPT ); Thu, 27 Mar 2008 06:21:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754390AbYC0KVW (ORCPT ); Thu, 27 Mar 2008 06:21:22 -0400 Received: from smtpeu1.atmel.com ([195.65.72.27]:50531 "EHLO bagnes.atmel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753322AbYC0KVW (ORCPT ); Thu, 27 Mar 2008 06:21:22 -0400 Date: Thu, 27 Mar 2008 11:20:48 +0100 From: Haavard Skinnemoen To: Dmitry Cc: "Russell King" , linux-kernel@vger.kernel.org, akpm@linux-foundation.org, hskinnemoen@atmel.com, lethal@linux-sh.org, tony@atomide.com, paul@pwsan.com Subject: Re: [PATCH 1/3] Clocklib: add generic framework for managing clocks. Message-ID: <20080327112048.014200cb@hskinnemo-gx620.norway.atmel.com> In-Reply-To: References: <20080326154913.GA15326@doriath.ww600.siemens.net> <20080326155203.GA15405@doriath.ww600.siemens.net> <20080326170441.795fb928@hskinnemo-gx620.norway.atmel.com> <20080327100623.34d92c84@hskinnemo-gx620.norway.atmel.com> <20080327091810.GA32396@flint.arm.linux.org.uk> <20080327102648.225d6b4f@hskinnemo-gx620.norway.atmel.com> <20080327093301.GB32396@flint.arm.linux.org.uk> <20080327105323.28a369fd@hskinnemo-gx620.norway.atmel.com> Organization: Atmel Norway X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.5; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2008 10:20:49.0036 (UTC) FILETIME=[3A2514C0:01C88FF4] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 955 Lines: 24 On Thu, 27 Mar 2008 13:08:37 +0300 Dmitry wrote: > I like this idea! This would also allow to cleanup the references code, etc. Great! > Also after I saw such refactored struct clk, I thought that it looks > nearly like kobject. Maybe we should switch to the kobject-based > structs? What do you think? I think that would be overkill. We should try to keep this stuff as lightweight as possible, and I'm not sure if we can give the kobject "parent" field the meaning we want it to have...or use the kref thing to do something unrelated to object lifecycle management (i.e. we don't want to destroy the object when the refcount goes to zero, we just want to stop the clock.) Haavard -- 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/