All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Alessandro Zummo <alessandro.zummo@towertech.it>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, Greg KH <greg@kroah.com>
Subject: Re: 2.6.16-rc4-mm2: drivers/rtc/utils.c should become part of a generic implementation
Date: Fri, 3 Mar 2006 23:26:17 +0100	[thread overview]
Message-ID: <20060303222617.GA9295@stusta.de> (raw)
In-Reply-To: <20060226200212.GD31256@flint.arm.linux.org.uk>

On Sun, Feb 26, 2006 at 08:02:12PM +0000, Russell King wrote:
> On Sun, Feb 26, 2006 at 07:55:18PM +0100, Adrian Bunk wrote:
> > On Sun, Feb 26, 2006 at 07:41:16PM +0100, Alessandro Zummo wrote:
> > > On Sat, 25 Feb 2006 14:10:25 +0100
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > 
> > > > 
> > > > Sounds good, but for generic functions, two adjustments are required:
> > > > - move the code to lib/
> > > > - remove rtc_ prefixes from the functions
> > > 
> > >  Moved. I'm not sure about renaming them.. 
> > > 
> > >  the functions are:
> > > 
> > > rtc_month_days
> > > rtc_time_to_tm
> > > rtc_valid_tm
> > > rtc_tm_to_time
> > > 
> > >  I think they make more sense with the rtc prefix
> > 
> > None of these functions is in any way specicific to RTC drivers.
> 
> Doesn't having them take a struct rtc_time (which is different from
> struct tm) make them rather RTC specific?

You are right, it seems I was a bit blind...

But in this case, it seems we don't need to build them unconditionally 
no matter whether RTC support is enabled in the kernel.

> Russell King

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2006-03-03 22:26 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-24 11:10 2.6.16-rc4-mm2 Andrew Morton
2006-02-24 16:27 ` [-mm PATCH] mips: fixed collision of rtc function name Yoichi Yuasa
2006-02-25 13:48   ` Atsushi Nemoto
2006-02-26 22:43     ` Yoichi Yuasa
2006-03-06 21:12       ` Ralf Baechle
2006-02-24 23:52 ` 2.6.16-rc4-mm2 Sam Ravnborg
2006-02-25  3:31 ` 2.6.16-rc4-mm2: drivers/rtc/utils.c should become part of a generic implementation Adrian Bunk
2006-02-25  4:46   ` Alessandro Zummo
2006-02-25 13:10     ` Adrian Bunk
2006-02-26 18:41       ` Alessandro Zummo
2006-02-26 18:55         ` Adrian Bunk
2006-02-26 20:02           ` Russell King
2006-03-03 22:26             ` Adrian Bunk [this message]
2006-02-25  3:38 ` 2.6.16-rc4-mm2: drivers/isdn/hysdn/hysdn_net.c module_param() compile error Adrian Bunk
2006-02-25  7:10   ` Rusty Russell
2006-02-25  7:22   ` Andrew Morton
2006-02-25  7:56     ` Rusty Russell
2006-02-25  3:47 ` oss/sonicvibes.c defines its own hweight32 Richard Knutsson
2006-02-25  4:11 ` 2.6.16-rc4-mm2: useless acpi_pmtmr_buggy Adrian Bunk
2006-02-25 11:59 ` 2.6.16-rc4-mm2 Jesper Juhl
2006-02-25 12:17   ` 2.6.16-rc4-mm2 Andrew Morton
2006-02-25 12:25     ` 2.6.16-rc4-mm2 Jesper Juhl
2006-02-25 12:31       ` 2.6.16-rc4-mm2 Andrew Morton
2006-02-25 12:41         ` 2.6.16-rc4-mm2 Jesper Juhl
2006-02-25 15:51           ` 2.6.16-rc4-mm2 Jesper Juhl
2006-02-26 23:38           ` 2.6.16-rc4-mm2 Antonino A. Daplas
2006-02-25 13:15 ` [-mm patch] drivers/media/video/cpia2/cpia2_v4l.c cleanups Adrian Bunk
2006-02-25 13:18 ` [-mm patch] kernel/params.c: make param_array() static Adrian Bunk
2006-02-25 13:21 ` [-mm patch] drivers/rtc/: make some structs static Adrian Bunk
2006-02-25 13:24 ` [-mm patch] kernel/fork.c: make signal_cachep static Adrian Bunk
2006-02-25 13:27 ` [-mm patch] net/dccp/ipv4.c: make struct dccp_v4_prot static Adrian Bunk
2006-02-25 14:31   ` Arnaldo Carvalho de Melo
2006-02-25 13:45 ` usbfs2 panic [Was: 2.6.16-rc4-mm2] Jiri Slaby
2006-02-25 18:05   ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060303222617.GA9295@stusta.de \
    --to=bunk@stusta.de \
    --cc=akpm@osdl.org \
    --cc=alessandro.zummo@towertech.it \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.