linux-kernel - Re: [PATCH 1/3] Clocklib: add generic framework for managing clocks.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bc64b4640803270308w6dc0723dr29e0ce5f20088d6d@mail.gmail.com>
Date:	Thu, 27 Mar 2008 13:08:37 +0300
From:	Dmitry <dbaryshkov@...il.com>
To:	"Haavard Skinnemoen" <haavard.skinnemoen@...el.com>
Cc:	"Russell King" <rmk+lkml@....linux.org.uk>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	hskinnemoen@...el.com, lethal@...ux-sh.org, tony@...mide.com,
	paul@...an.com
Subject: Re: [PATCH 1/3] Clocklib: add generic framework for managing clocks.

Hi,

2008/3/27, Haavard Skinnemoen <haavard.skinnemoen@...el.com>:
> [domen.puncer@...argo.com keeps bouncing on me, removed from Cc]
>
>  On Thu, 27 Mar 2008 09:33:01 +0000
>
> Russell King <rmk+lkml@....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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/