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 04:57:02 -0500	[thread overview]
Message-ID: <4D5CF0EE.7000308@gentoo.org> (raw)
In-Reply-To: <4D5C5C66.6060205@metafoo.de>

On 02/16/2011 18:23, Lars-Peter Clausen wrote:

> Just pass the error up to rtc core.

How?  I looked at a few other drivers, but they, too, call dev_err() or 
dev_dbg().  Others don't appear to send any kind of string-based error value 
anywhere, they just return a -E* value.


> There is no need for these checks the core takes care that the values are valid.

I've seen a few other RTC drivers implement these checks.  It's really hard to 
tell what drivers are, I guess, "right" and which ones are "wrong" in their 
approach when you've got already-accepted drivers in the tree doing things that 
I'm trying to fix in this driver.

That said, how is the core running these checks when I quickly turn around and 
write the values back to the RTC?


> 	return rtc_valid_tm(&arlm->time);

Noted -- Probably form when I copied one of the time read functions or such. 
Alarm support wasn't in the original version of this driver when I found it.


> Why has 'enabled' to be a pointer?

No idea to be honest.  I think I copied it from another driver.  I'll re-review 
it when I get to that point in fixing things.


> resource_size(res) instead of res->end - res->start + 1
> and it would be easier to just save the pointer to res instead of saving both
> size and start;

Noted, I see a few drivers using this syntax, so I'll adapt to it.


> If CONFIG_SYSFS is not defined you'll get an compile error.

Noted, thanks!


> Since the irq handler references the rtc device it should be freed before the
> rtc device.

Noted, thanks!


> There doesn't seem to be any code inside this file which is used outside of
> ds1685.c so it might be a good idea to merge the two files, or at least move
> this file to drivers/rtc/

I wasn't quite sure where headers typically went.  include/linux/rtc already 
existed, so I thought it was created at some point for holding .h files for RTC 
drivers.  IP32 will need to reference this header down the road anyways.  No 
harm if it has to look into drivers/rtc?


> Just use BIT(x) instead of adding these defines

Noted, will research.


> 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.

Working on this now.  Ran into some road blocks with gcc and inlining, but I 
worked around it.


> All these macros that follow should really be functions.

Even the large ds1685_begin_data_access macro?  I can stick it into a inlined 
function, but I thought a macro was better.  Or am I trying to outfox the 
compiler by doing so?

If I do inline it, I need a fix for passing errors back to the RTC core.  I 
can't use dev_err() because it needs the device struct to work with, and I want 
to avoid passing too many arguments to an inlinable function.

Thoughts?  The rest should be easy to convert into inlined functions.


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

  parent reply	other threads:[~2011-02-17  9:57 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
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 [this message]
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=4D5CF0EE.7000308@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.