Messages in this thread | | | Date | Thu, 27 Mar 2008 13:08:37 +0300 | From | Dmitry <> | Subject | Re: [PATCH 1/3] Clocklib: add generic framework for managing clocks. |
| |
Hi,
2008/3/27, Haavard Skinnemoen <haavard.skinnemoen@atmel.com>: > [domen.puncer@telargo.com keeps bouncing on me, removed from Cc] > > On Thu, 27 Mar 2008 09:33:01 +0000 > > Russell King <rmk+lkml@arm.linux.org.uk> wrote: > > > > On Thu, Mar 27, 2008 at 10:26:48AM +0100, Haavard Skinnemoen wrote: > > > You can extend the struct, put the rate there and use the same > > > getrate() function for all the clocks that need to keep track of the > > > current rate this way. > > > > Well, if you're really concerned about size, you could do what I did with > > PXA and introduce a struct clk_ops to contain all the constant function > > pointers, rather than mashing the function pointers together - which > > saves far more than trying to combine them. > > > I don't see what this has to do with the paragraph you quoted, but > yeah, good point. I don't think it should be used as an excuse for > filling up struct clk with platform-specific crap, however. > > So how about something like this? > > struct clk_ops { > struct module *owner; > > > int (*can_get) (struct clk *, struct device *); > int (*set_parent) (struct clk *, struct clk *); > > int (*enable) (struct clk *); > void (*disable) (struct clk *); > > unsigned long (*getrate) (struct clk*); > > int (*setrate) (struct clk *, unsigned long); > > long (*roundrate) (struct clk *, unsigned long); > > }; > > > struct clk { > struct list_head node; > struct clk *parent; > > const char *name; > > int users; > > const struct clk_ops *ops; > };
I like this idea! This would also allow to cleanup the references code, etc. 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?
-- With best wishes Dmitry
| |