linux-kernel - Re: [PATCH 0/5] Clocklib: generic clocks framework

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]

Date:	Mon, 21 Apr 2008 01:44:12 -0600 (MDT)
From:	Paul Walmsley <paul@...an.com>
To:	Dmitry Baryshkov <dbaryshkov@...il.com>
cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	Haavard Skinnemoen <haavard.skinnemoen@...el.com>,
	Russell King <rmk+lkml@....linux.org.uk>,
	Paul Mundt <lethal@...ux-sh.org>,
	pHilipp Zabel <philipp.zabel@...il.com>,
	Pavel Machek <pavel@....cz>, tony@...mide.com,
	David Brownell <david-b@...bell.net>, hiroshi.DOYU@...ia.com
Subject: Re: [PATCH 0/5] Clocklib: generic clocks framework

Hello Dmitry,

By way of introduction, I've been working on the Linux-OMAP clock tree 
over the past several months.  I recently had the opportunity to take a 
brief look at these clocklib patches that you're posting, and had a few 
thoughts:

- I understand from the discussions in this thread that the usage of your 
  clocklib code will be optional. However, the way you implement various 
  parts of the clock interface may effectively become mandatory, and 
  clocklib may not be able to handle many of the platform-specific clock 
  details that are necessary with more complex clock layouts like OMAP.  
  Would you consider the main goal of your clocklib code to be simply the 
  removal of several of the simpler ARM clock tree implementations?  Or is 
  your intention for it to ultimately replace all of the current Linux 
  clock implementations?  If the latter, your patchset will presumably 
  need a higher standard of review, since once it is integrated, any 
  changes will affect several architectures, rather than simply one.

- As others have mentioned earlier on this thread, it seems difficult to 
  construct a good "one-size-fits-all" struct clk.  At the very least, 
  I would also suggest adding a 'void *' to allow storage of clock-specific 
  data.

- Hiroshi DOYU has proposed an alternate debugfs implementation for the
  Linux-OMAP clock tree.  I prefer it to yours, as it implements each 
  clock as a separate dentry, which makes it easy to implement additional 
  debugging functions, such as set_rate/set_parent/round_rate debugging.  
  Perhaps you'd consider it, or something similar to it, instead?  It is 
  proposed here:
     http://www.mail-archive.com/linux-omap@vger.kernel.org/msg00751.html

- I don't think that I understand the clk_functions part of your code.  
  Is this a shorthand to construct aliases to other struct clks?


regards,

- Paul
--
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/