All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kumba <kumba@gentoo.org>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: Linux MIPS List <linux-mips@linux-mips.org>, rtc-linux@googlegroups.com
Subject: Re: [PATCH 1/2]: Add support for Dallas/Maxim DS1685/1687 RTC
Date: Thu, 17 Feb 2011 00:45:31 -0500	[thread overview]
Message-ID: <4D5CB5FB.20305@gentoo.org> (raw)
In-Reply-To: <4D5C5C66.6060205@metafoo.de>

On 02/16/2011 18:23, Lars-Peter Clausen wrote:
> I think you should really use readb(pdata->regs + REG) instead of the following
> structs. Maybe add a helper function in the form of:
> static uint8_t ds1685_read(struct ds1685_priv *ds1685, unsigned int reg) {
> 	return readb(pdata->regs + REG);
> }
>
> That should also help with the different paddings introduced in patch 2.

Lots of good feedback, thanks!  Ralf already suggested using offsets instead of 
a struct.  I'm tinkering now with getting this to work, as I have to have this 
done before I can address many of your other points.

I have determined the following formula specific to the SGI O2 to read the RTC 
registers:

readb(pdata->regs + RTC_<REGISTER> * 0x100);

is equivalent to

readb(pdata->regs.time.<REGISTER>);

I'll assume writeb() changes are the same.  The question is, how do I wire in 
the 0x100 padding value in such a way that I keep the IP32-specific bits out of 
generic code?  Ralf mentioned using some field in platform_data, but I haven't 
quite learned the platform stuff (this is my first real attempt at a kernle driver).

Also, one thing I can quickly address, I put the ds1685.h file under 
include/linux/rtc because I saw that folder as already existing.  I figured 
that's where rtc header files went.  Right now, nothing outside of the driver 
uses it, but SGI O2 will need to eventually, as it uses the RTC to trigger a 
system poweroff by accessing a few of the extended control registers.

It currently uses similarly-duplicated #defines in a local header file, but I 
figured, if I can get this driver fully working, and other platforms could 
theoretically use the same trick, would not include/linux/rtc be the best place 
for the header?  If there's a better place, please let me know!

Thanks,

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org

"The past tempts us, the present confuses us, the future frightens us.  And our 
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

  reply	other threads:[~2011-02-17  5:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-15 11:39 [PATCH 1/2]: Add support for Dallas/Maxim DS1685/1687 RTC Kumba
2011-02-16 23:23 ` Lars-Peter Clausen
2011-02-17  5:45   ` Kumba [this message]
2011-02-17  7:31     ` Manuel Lauss
2011-02-17  8:17       ` Kumba
2011-02-17  8:39         ` Manuel Lauss
2011-02-17  9:57   ` Kumba
2011-02-17 11:43     ` Lars-Peter Clausen
2011-02-17 18:47       ` Kumba
2011-02-18 11:02       ` Kumba

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=4D5CB5FB.20305@gentoo.org \
    --to=kumba@gentoo.org \
    --cc=lars@metafoo.de \
    --cc=linux-mips@linux-mips.org \
    --cc=rtc-linux@googlegroups.com \
    /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.