Linux RTC
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
	Alexandre Belloni <alexandre.belloni@free-electrons.com>,
	rtc-linux@googlegroups.com, Arnaud Ebalard <arno@natisbad.org>,
	Jason Cooper <jason@lakedaemon.net>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	linux-arm-kernel@lists.infradead.org,
	Lior Amsalem <alior@marvell.com>,
	Tawfik Bayouk <tawfik@marvell.com>,
	Nadav Haklai <nadavh@marvell.com>,
	stable@vger.kernel.org
Subject: [rtc-linux] Re: [PATCH] rtc: armada38x: Fix concurrency access in armada38x_rtc_set_time
Date: Fri, 17 Apr 2015 15:17:34 +0200	[thread overview]
Message-ID: <20150417131734.GB7768@lunn.ch> (raw)
In-Reply-To: <5531070A.7080105@free-electrons.com>

On Fri, Apr 17, 2015 at 03:13:46PM +0200, Gregory CLEMENT wrote:
> Hi Andrew,
> 
> On 15/04/2015 21:27, Andrew Lunn wrote:
> > On Wed, Apr 15, 2015 at 03:13:53PM +0200, Gregory CLEMENT wrote:
> >> While setting the time, the RTC TIME register should not be
> >> accessed. However due to hardware constraints, setting the RTC time
> >> involves sleeping during 100ms. This sleep was done outside the
> >> critical section protected by the spinlock, so it was possible to read
> >> the RTC TIME register and get an incorrect value. This patch
> >> introduces a mutex for protecting the RTC TIME access, unlike the
> >> spinlock it is allowed to sleep in a critical section protected by a
> >> mutex. The RTC STATUS register can still be used from the interrupt
> >> handler but it has no effect on setting the time.
> > 
> > Hi Gregory
> > 
> > There is the following comment in the code:
> > 
> >         /*
> >          * Setting the RTC time not always succeeds. According to the
> >          * errata we need to first write on the status register and
> >          * then wait for 100ms before writing to the time register to be
> >          * sure that the data will be taken into account.
> >          */
> > 
> > The interrupt handler also writes to the STATUS register. So what
> > happens if there is an interrupt during that 100ms and a second write
> > to STATUS?
> 
> 
> As I wrote in the commit log, the RTC STATUS register can still be used from
> the interrupt handler but it has no effect on setting the time: between writing
> 0 in the RTC_STATUS register and writing the time in the RTC_TIME register,
> writing anything in RTC_STATUS won't prevent to write the time successfully.

Hi Gregory

Thanks for explaining. If you have to respin for any reason, it would
be nice to make the commit log more explicit about this.

I didn't do a detailed review, but i did review it to some extent, so

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

   Andrew

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

  reply	other threads:[~2015-04-17 13:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-15 13:13 [rtc-linux] [PATCH] rtc: armada38x: Fix concurrency access in armada38x_rtc_set_time Gregory CLEMENT
2015-04-15 19:27 ` [rtc-linux] " Andrew Lunn
2015-04-17 13:13   ` Gregory CLEMENT
2015-04-17 13:17     ` Andrew Lunn [this message]
2015-04-17 13:42 ` Alexandre Belloni

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=20150417131734.GB7768@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=alior@marvell.com \
    --cc=arno@natisbad.org \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=gregory.clement@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=nadavh@marvell.com \
    --cc=rtc-linux@googlegroups.com \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=tawfik@marvell.com \
    --cc=thomas.petazzoni@free-electrons.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox