All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Cartwright <joshc@eso.teric.us>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
	rtc-linux@googlegroups.com, linux-kernel@vger.kernel.org
Subject: [rtc-linux] Re: [PATCH] rtc: Add a driver for Micro Crystal RV8803
Date: Sun, 27 Sep 2015 22:04:34 -0500	[thread overview]
Message-ID: <20150928030434.GJ3543@kryptos> (raw)
In-Reply-To: <1443275679-21459-1-git-send-email-alexandre.belloni@free-electrons.com>

Hello Alexandre-

Few comments below.

On Sat, Sep 26, 2015 at 03:54:39PM +0200, Alexandre Belloni wrote:
> This driver supports the following functions:
>  - reading and settings time
>  - alarms when connected to an IRQ
>  - reading and clearing the voltage low flags
>  - nvram
> 
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
[..]
> +static irqreturn_t rv8803_handle_irq(int irq, void *dev_id)
> +{
> +	struct i2c_client *client = dev_id;
> +	struct rv8803_data *rv8803 = i2c_get_clientdata(client);
> +	unsigned long events = 0;
> +	u8 flags;
> +
> +	flags = i2c_smbus_read_byte_data(client, RV8803_FLAG);
> +	if (flags <= 0)
> +		return IRQ_HANDLED;

Returning IRQ_HANDLED when no interrupt condition is met.  That seems
like a bad idea.

> +	if (flags & RV8803_FLAG_V1F)
> +		dev_warn(&client->dev, "Voltage low, temperature compensation stopped.\n");
> +
> +	if (flags & RV8803_FLAG_V2F)
> +		dev_warn(&client->dev, "Voltage low, data loss detected.\n");
> +
> +	if (flags & RV8803_FLAG_TF) {
> +		flags &= ~RV8803_FLAG_TF;
> +		rv8803->ctrl &= ~RV8803_CTRL_TIE;
> +		events |= RTC_PF;
> +	}
> +
> +	if (flags & RV8803_FLAG_AF) {
> +		flags &= ~RV8803_FLAG_AF;
> +		rv8803->ctrl &= ~RV8803_CTRL_AIE;
> +		events |= RTC_AF;
> +	}
> +
> +	if (flags & RV8803_FLAG_UF) {
> +		flags &= ~RV8803_FLAG_UF;
> +		rv8803->ctrl &= ~RV8803_CTRL_UIE;
> +		events |= RTC_UF;
> +	}
> +
> +	if (events) {
> +		rtc_update_irq(rv8803->rtc, 1, events);
> +		i2c_smbus_write_byte_data(client, RV8803_FLAG, flags);

How are the many read-modify-write cycles for flags safe without any
form of synchronization?  (Especially given the interrupt handler isn't
under ops_lock).

> +		i2c_smbus_write_byte_data(rv8803->client, RV8803_CTRL,
> +					  rv8803->ctrl);
> +	}
> +
> +	return IRQ_HANDLED;
> +}
> +
[..]
> +static int rv8803_get_alarm(struct device *dev, struct rtc_wkalrm *alrm)
> +{
> +	struct rv8803_data *rv8803 = dev_get_drvdata(dev);
> +	struct i2c_client *client = rv8803->client;
> +	u8 alarmvals[3];
> +	int flags, ret;
> +
> +	if (client->irq <= 0)
> +		return -EINVAL;

It'd be cleaner just to have a second set of rtc_class_ops that can be
switched between based on whether a valid interrupt is specified.

  Josh

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

WARNING: multiple messages have this Message-ID (diff)
From: Josh Cartwright <joshc@eso.teric.us>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
	rtc-linux@googlegroups.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rtc: Add a driver for Micro Crystal RV8803
Date: Sun, 27 Sep 2015 22:04:34 -0500	[thread overview]
Message-ID: <20150928030434.GJ3543@kryptos> (raw)
In-Reply-To: <1443275679-21459-1-git-send-email-alexandre.belloni@free-electrons.com>

Hello Alexandre-

Few comments below.

On Sat, Sep 26, 2015 at 03:54:39PM +0200, Alexandre Belloni wrote:
> This driver supports the following functions:
>  - reading and settings time
>  - alarms when connected to an IRQ
>  - reading and clearing the voltage low flags
>  - nvram
> 
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
[..]
> +static irqreturn_t rv8803_handle_irq(int irq, void *dev_id)
> +{
> +	struct i2c_client *client = dev_id;
> +	struct rv8803_data *rv8803 = i2c_get_clientdata(client);
> +	unsigned long events = 0;
> +	u8 flags;
> +
> +	flags = i2c_smbus_read_byte_data(client, RV8803_FLAG);
> +	if (flags <= 0)
> +		return IRQ_HANDLED;

Returning IRQ_HANDLED when no interrupt condition is met.  That seems
like a bad idea.

> +	if (flags & RV8803_FLAG_V1F)
> +		dev_warn(&client->dev, "Voltage low, temperature compensation stopped.\n");
> +
> +	if (flags & RV8803_FLAG_V2F)
> +		dev_warn(&client->dev, "Voltage low, data loss detected.\n");
> +
> +	if (flags & RV8803_FLAG_TF) {
> +		flags &= ~RV8803_FLAG_TF;
> +		rv8803->ctrl &= ~RV8803_CTRL_TIE;
> +		events |= RTC_PF;
> +	}
> +
> +	if (flags & RV8803_FLAG_AF) {
> +		flags &= ~RV8803_FLAG_AF;
> +		rv8803->ctrl &= ~RV8803_CTRL_AIE;
> +		events |= RTC_AF;
> +	}
> +
> +	if (flags & RV8803_FLAG_UF) {
> +		flags &= ~RV8803_FLAG_UF;
> +		rv8803->ctrl &= ~RV8803_CTRL_UIE;
> +		events |= RTC_UF;
> +	}
> +
> +	if (events) {
> +		rtc_update_irq(rv8803->rtc, 1, events);
> +		i2c_smbus_write_byte_data(client, RV8803_FLAG, flags);

How are the many read-modify-write cycles for flags safe without any
form of synchronization?  (Especially given the interrupt handler isn't
under ops_lock).

> +		i2c_smbus_write_byte_data(rv8803->client, RV8803_CTRL,
> +					  rv8803->ctrl);
> +	}
> +
> +	return IRQ_HANDLED;
> +}
> +
[..]
> +static int rv8803_get_alarm(struct device *dev, struct rtc_wkalrm *alrm)
> +{
> +	struct rv8803_data *rv8803 = dev_get_drvdata(dev);
> +	struct i2c_client *client = rv8803->client;
> +	u8 alarmvals[3];
> +	int flags, ret;
> +
> +	if (client->irq <= 0)
> +		return -EINVAL;

It'd be cleaner just to have a second set of rtc_class_ops that can be
switched between based on whether a valid interrupt is specified.

  Josh

  parent reply	other threads:[~2015-09-28  3:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-26 14:42 [rtc-linux] drivers/rtc/rtc-rv8803.c:494:3-8: No need to set .owner here. The core will do it kbuild test robot
2015-09-26 14:42 ` kbuild test robot
2015-09-26 13:54 ` [rtc-linux] [PATCH] rtc: Add a driver for Micro Crystal RV8803 Alexandre Belloni
2015-09-26 13:54   ` Alexandre Belloni
2015-09-26 14:42   ` [rtc-linux] [PATCH] rtc: fix platform_no_drv_owner.cocci warnings kbuild test robot
2015-09-26 14:42     ` kbuild test robot
2015-09-28  3:04   ` Josh Cartwright [this message]
2015-09-28  3:04     ` [PATCH] rtc: Add a driver for Micro Crystal RV8803 Josh Cartwright
2015-09-28  6:16   ` [rtc-linux] [PATCH] rtc: fix platform_no_drv_owner.cocci warnings kbuild test robot
2015-09-28  6:16     ` kbuild test robot
2015-09-28  6:16   ` [rtc-linux] Re: [PATCH] rtc: Add a driver for Micro Crystal RV8803 kbuild test robot
2015-09-28  6:16     ` kbuild test robot

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=20150928030434.GJ3543@kryptos \
    --to=joshc@eso.teric.us \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=linux-kernel@vger.kernel.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.