diff mbox

[2/2] rtc/ab8500: Remove fix for AB8500 ED version

Message ID 1339940724-6963-1-git-send-email-linus.walleij@stericsson.com
State Accepted
Headers show

Commit Message

Linus Walleij June 17, 2012, 1:45 p.m. UTC 
From: Bengt Jonsson <bengt.g.jonsson@stericsson.com>

AB8500 ED (Early Drop) is no longer supported by the kernel.

Signed-off-by: Bengt Jonsson <bengt.g.jonsson@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/rtc/rtc-ab8500.c |   27 +++++++++++----------------
 1 file changed, 11 insertions(+), 16 deletions(-)

Comments

Andrew Morton June 20, 2012, 10:52 p.m. UTC | #1 
I don't know what the end-user-visible effects of these two patches
are.  I've assumed "not needed in 3.5 or earler".  If that was a
mistake, please let me know and send along appropriate changelog text so
that others can understand the decision.

Thanks.
Linus Walleij June 21, 2012, 6:26 a.m. UTC | #2 
On Thu, Jun 21, 2012 at 12:52 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:

> I don't know what the end-user-visible effects of these two patches
> are.  I've assumed "not needed in 3.5 or earler".  If that was a
> mistake, please let me know and send along appropriate changelog text so
> that others can understand the decision.

OK I usually do it the other way around, i.e. if something is
an urgent fix or regression I try to stress that, then everything
else is implicitly for the next merge window.

I will try to use a [0/n] patch telling that the set is for the next
merge window for the RTC stuff, that should work I think?

Yours,
Linus Walleij
Andrew Morton June 21, 2012, 8:44 a.m. UTC | #3 
On Thu, 21 Jun 2012 08:26:49 +0200 Linus Walleij <linus.walleij@linaro.org> wrote:

> On Thu, Jun 21, 2012 at 12:52 AM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> 
> > I don't know what the end-user-visible effects of these two patches
> > are. __I've assumed "not needed in 3.5 or earler". __If that was a
> > mistake, please let me know and send along appropriate changelog text so
> > that others can understand the decision.
> 
> OK I usually do it the other way around, i.e. if something is
> an urgent fix or regression I try to stress that, then everything
> else is implicitly for the next merge window.
> 
> I will try to use a [0/n] patch telling that the set is for the next
> merge window for the RTC stuff, that should work I think?

Well that doesn't hurt, but ideally each patch's changelog should
permit readers to understand the impact of the patch on users.  These
patches didn't do that.
diff mbox

Patch

diff --git a/drivers/rtc/rtc-ab8500.c b/drivers/rtc/rtc-ab8500.c
index 60e43ab..5268d9d 100644
--- a/drivers/rtc/rtc-ab8500.c
+++ b/drivers/rtc/rtc-ab8500.c
@@ -88,22 +88,17 @@  static int ab8500_rtc_read_time(struct device *dev, struct rtc_time *tm)
 	if (retval < 0)
 		return retval;
 
-	/* Early AB8500 chips will not clear the rtc read request bit */
-	if (abx500_get_chip_id(dev) == 0) {
-		usleep_range(1000, 1000);
-	} else {
-		/* Wait for some cycles after enabling the rtc read in ab8500 */
-		while (time_before(jiffies, timeout)) {
-			retval = abx500_get_register_interruptible(dev,
-				AB8500_RTC, AB8500_RTC_READ_REQ_REG, &value);
-			if (retval < 0)
-				return retval;
-
-			if (!(value & RTC_READ_REQUEST))
-				break;
-
-			usleep_range(1000, 5000);
-		}
+	/* Wait for some cycles after enabling the rtc read in ab8500 */
+	while (time_before(jiffies, timeout)) {
+		retval = abx500_get_register_interruptible(dev,
+			AB8500_RTC, AB8500_RTC_READ_REQ_REG, &value);
+		if (retval < 0)
+			return retval;
+
+		if (!(value & RTC_READ_REQUEST))
+			break;
+
+		usleep_range(1000, 5000);
 	}
 
 	/* Read the Watchtime registers */