All of lore.kernel.org
 help / color / mirror / Atom feed
From: mcuelenaere@gmail.com (Maurus Cuelenaere)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH]: S3C RTC driver: add support for S3C64xx
Date: Tue, 10 Nov 2009 17:46:01 +0100	[thread overview]
Message-ID: <4AF998C9.3060208@gmail.com> (raw)
In-Reply-To: <1b68c6790911100553m267f35dav9638fc6c0340978d@mail.gmail.com>

Op 10-11-09 14:53, jassi brar schreef:
> On Tue, Nov 10, 2009 at 10:46 AM, Maurus Cuelenaere
> <mcuelenaere@gmail.com>  wrote:
>    
>> <snip>
>>
>> +static struct s3c_rtc_platdata s3c_rtc_pdata = {
>> +       .rtc_type       = 0,
>> +};
>>      
> 1) where is this structure defined?
>      Perhaps u forgot to share the plat/rtc.h
>    

Hmm seems I did forgot to include plat/rtc.h ..

> 2) rtc_type isn't very neat. Runtime CPU detection is better.
>   Even better, if you manage to segregate the differences between
> two versions and pass them via platform data somehow.
> For, example, driver could assume resolution as pdata->resolution
> instead of 128 or 32768 or whatever for future SoCs.
>    

pdata->resolution sounds like a good idea.

>> <snip>
>>   #else
>> @@ -518,7 +563,7 @@ static struct platform_driver s3c2410_rtc_driver = {
>>         .suspend        = s3c_rtc_suspend,
>>         .resume         = s3c_rtc_resume,
>>         .driver         = {
>> -               .name   = "s3c2410-rtc",
>> +               .name   = "s3c-rtc",
>>                 .owner  = THIS_MODULE,
>>         },
>>   };
>>      
> why not use platform_device_id ?
>    

I didn't know of platform_device_id, looks like a clean(er) solution for 
this.


I'll post an updated patch with Jassi's and Ben's remarks in mind.

Regards,
Maurus Cuelenaere

  reply	other threads:[~2009-11-10 16:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-10  1:46 [PATCH]: S3C RTC driver: add support for S3C64xx Maurus Cuelenaere
2009-11-10 10:52 ` Ben Dooks
2009-11-10 13:53 ` jassi brar
2009-11-10 16:46   ` Maurus Cuelenaere [this message]
     [not found] <b2e8f9f71001111640u6fd95121o42fcb6e4b7475353@mail.gmail.com>
2010-03-08 20:12 ` [PATCH] " Maurus Cuelenaere
2010-03-08 21:34   ` Frans Pop
2010-03-08 21:44     ` Maurus Cuelenaere
  -- strict thread matches above, loose matches on Subject: below --
2010-03-22 11:26 Maurus Cuelenaere
2010-03-23  3:26 ` Andrew Morton
2010-03-23  8:10 Maurus Cuelenaere

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=4AF998C9.3060208@gmail.com \
    --to=mcuelenaere@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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.