Re: [RFC][PATCH 1/2] Clocklib: add generic framework for managing clocks.

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Dmitry Baryshkov <dbaryshkov@...>
Cc: <linux-kernel@...>, <haavard.skinnemoen@...>, <rmk+lkml@...>, <lethal@...>, <philipp.zabel@...>, <pavel@...>, <tony@...>, <paul@...>, <david-b@...>
Date: Tuesday, May 27, 2008 - 6:09 pm

On Fri, 23 May 2008 01:21:42 +0400
Dmitry Baryshkov <dbaryshkov@gmail.com> wrote:


Nobody interested in this?

Please feed the patches through scripts/checkpatch.pl sometime, have a
think about the things which it detects?


`set_mode' seems to be misnamed?

We prefer to avoid functions which take a `heres-what-to-do' argument
like this.  I'd have thought that it would be cleaner to have separate
`enable' and `disable' operations?

The documentation should perhaps explain that set_mode() is called
under spin_lock_irqsave() and hence cannot do much.


This could-and-should be GFP_KERNEL.


The patch generally has nice documentation, but these two major
interface functions were omitted.


Hopefully this function will not be called at a high frequency.  If it
is, scalability will be poor.

Why does clocks_lock need to be taken in an irq-safe manner?


Unneeded newline.


Did we really need to hold the lock to perform this check?

Is it really valid for a clock to have no ->ops and no -ops->get_rate? 
Please consider mandating that these fields must be provided, then
remove this check.


I look at this and wonder what unit `rate' is in.  Some interface
documentation would clear that up, but even better would be to use a
more specific identifier - one which describes the quantity's units. 
For example, "hz".


ditto everywhere


Was `long' an appropriate type here?  I'd have expected `unsigned long'.

Perhaps this can really retrun negative values.  Aditional
documentation would clear that up.


This can_get operation is a bit mysterious and unusual-looking.  Why
would one not be able to get a clock device?

Again, additional changelogging and/or code commenting is needed,
because if I was wondering this now, we can expect that others will
wonder the same thing in the future.


I guess that printk is temporary?


Can we avoid the (mysterious) void* here?  Do something which will
allow the C type system to check our stuff?


--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC][PATCH 0/2] Clocklib: generic clocks framework, Dmitry Baryshkov, (Thu May 22, 5:19 pm)
Re: [RFC][PATCH 1/2] Clocklib: add generic framework for man..., Andrew Morton, (Tue May 27, 6:09 pm)
Re: [RFC][PATCH 1/2] Clocklib: add generic framework for man..., Haavard Skinnemoen, (Wed May 28, 3:44 am)
Re: [RFC][PATCH 1/2] Clocklib: add generic framework for man..., Haavard Skinnemoen, (Wed May 28, 9:56 am)
Re: [RFC][PATCH 1/2] Clocklib: add generic framework for man..., Dmitry Baryshkov, (Wed May 28, 11:34 am)
Re: [RFC][PATCH 1/2] Clocklib: add generic framework for man..., Haavard Skinnemoen, (Wed May 28, 3:52 pm)