All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: linux-kernel@vger.kernel.org, Kukjin Kim <kgene@kernel.org>,
	rtc-linux@googlegroups.com, Chanwoo Choi <cw00.choi@samsung.com>,
	Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	Laxman Dewangan <ldewangan@nvidia.com>,
	linux-samsung-soc@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Olof Johansson <olof@lixom.net>,
	linux-arm-kernel@lists.infradead.org
Subject: [rtc-linux] Re: [PATCH v2 00/10] rtc: max77686: Extend driver and add max77802 support
Date: Mon, 25 Jan 2016 17:06:33 +0100	[thread overview]
Message-ID: <20160125160633.GB11740@piout.net> (raw)
In-Reply-To: <1453407813-14646-1-git-send-email-javier@osg.samsung.com>

Hi,

On 21/01/2016 at 17:23:23 -0300, Javier Martinez Canillas wrote :
> On a recent disussion [0] with Krzysztof Kozlowski and Laxman Dewangan,
> we came to the conclusion that the max77686 and max77802 RTC are almost
> the same with only a few differences so there shouldn't be two separate
> drivers and is better to extend max77686 driver and delete rtc-max77802.
> 
> By making the driver more generic, other RTC IP blocks from Maxim PMICs
> could be supported as well like the max77620.
> 
> This is a v2 of a series that do this, that address issues pointed out
> by Krzysztof Kozlowski. The v1 can be found at [1].
> 
> I've tested this patch-set on an Exynos5800 Peach Pi Chromebook that has
> a max77802 PMIC and the RTC was working correctly but I don't have a
> machine with max77686 so I will really appreaciate if someone can test
> that no regressions were introduced.
> 
> On an IRC conversation, Alexandre suggested to use the field support in
> the regmap API to avoid needing a translation table. I spent some time
> to look at it and I'm not so sure if it fits that well in this case.
> 
> It's true that we could model each register as if it has a single field
> and provide a different reg address but I'm not sure if that would make
> things more clear or cause more confusion for future code archaeologists.
> 

Yeah, Mark suggested that regmap_field may be what we were looking for
but I'm not convinced it really fits.

> In any case, I think this series are a move in the right direction since
> removes code duplication and a complete driver and also allows others to
> reuse the driver for another RTC chip. We can later simplify and use the
> regmap field API or extend the regmap core if that could make things even
> simpler but I propose to do it as a follow up.
> 

I don't have any objection or other comment on that series. So
basically, I'm waiting for v3 and I'll apply it.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
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: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: linux-kernel@vger.kernel.org, Kukjin Kim <kgene@kernel.org>,
	rtc-linux@googlegroups.com, Chanwoo Choi <cw00.choi@samsung.com>,
	Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	Laxman Dewangan <ldewangan@nvidia.com>,
	linux-samsung-soc@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Olof Johansson <olof@lixom.net>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 00/10] rtc: max77686: Extend driver and add max77802 support
Date: Mon, 25 Jan 2016 17:06:33 +0100	[thread overview]
Message-ID: <20160125160633.GB11740@piout.net> (raw)
In-Reply-To: <1453407813-14646-1-git-send-email-javier@osg.samsung.com>

Hi,

On 21/01/2016 at 17:23:23 -0300, Javier Martinez Canillas wrote :
> On a recent disussion [0] with Krzysztof Kozlowski and Laxman Dewangan,
> we came to the conclusion that the max77686 and max77802 RTC are almost
> the same with only a few differences so there shouldn't be two separate
> drivers and is better to extend max77686 driver and delete rtc-max77802.
> 
> By making the driver more generic, other RTC IP blocks from Maxim PMICs
> could be supported as well like the max77620.
> 
> This is a v2 of a series that do this, that address issues pointed out
> by Krzysztof Kozlowski. The v1 can be found at [1].
> 
> I've tested this patch-set on an Exynos5800 Peach Pi Chromebook that has
> a max77802 PMIC and the RTC was working correctly but I don't have a
> machine with max77686 so I will really appreaciate if someone can test
> that no regressions were introduced.
> 
> On an IRC conversation, Alexandre suggested to use the field support in
> the regmap API to avoid needing a translation table. I spent some time
> to look at it and I'm not so sure if it fits that well in this case.
> 
> It's true that we could model each register as if it has a single field
> and provide a different reg address but I'm not sure if that would make
> things more clear or cause more confusion for future code archaeologists.
> 

Yeah, Mark suggested that regmap_field may be what we were looking for
but I'm not convinced it really fits.

> In any case, I think this series are a move in the right direction since
> removes code duplication and a complete driver and also allows others to
> reuse the driver for another RTC chip. We can later simplify and use the
> regmap field API or extend the regmap core if that could make things even
> simpler but I propose to do it as a follow up.
> 

I don't have any objection or other comment on that series. So
basically, I'm waiting for v3 and I'll apply it.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: alexandre.belloni@free-electrons.com (Alexandre Belloni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 00/10] rtc: max77686: Extend driver and add max77802 support
Date: Mon, 25 Jan 2016 17:06:33 +0100	[thread overview]
Message-ID: <20160125160633.GB11740@piout.net> (raw)
In-Reply-To: <1453407813-14646-1-git-send-email-javier@osg.samsung.com>

Hi,

On 21/01/2016 at 17:23:23 -0300, Javier Martinez Canillas wrote :
> On a recent disussion [0] with Krzysztof Kozlowski and Laxman Dewangan,
> we came to the conclusion that the max77686 and max77802 RTC are almost
> the same with only a few differences so there shouldn't be two separate
> drivers and is better to extend max77686 driver and delete rtc-max77802.
> 
> By making the driver more generic, other RTC IP blocks from Maxim PMICs
> could be supported as well like the max77620.
> 
> This is a v2 of a series that do this, that address issues pointed out
> by Krzysztof Kozlowski. The v1 can be found at [1].
> 
> I've tested this patch-set on an Exynos5800 Peach Pi Chromebook that has
> a max77802 PMIC and the RTC was working correctly but I don't have a
> machine with max77686 so I will really appreaciate if someone can test
> that no regressions were introduced.
> 
> On an IRC conversation, Alexandre suggested to use the field support in
> the regmap API to avoid needing a translation table. I spent some time
> to look at it and I'm not so sure if it fits that well in this case.
> 
> It's true that we could model each register as if it has a single field
> and provide a different reg address but I'm not sure if that would make
> things more clear or cause more confusion for future code archaeologists.
> 

Yeah, Mark suggested that regmap_field may be what we were looking for
but I'm not convinced it really fits.

> In any case, I think this series are a move in the right direction since
> removes code duplication and a complete driver and also allows others to
> reuse the driver for another RTC chip. We can later simplify and use the
> regmap field API or extend the regmap core if that could make things even
> simpler but I propose to do it as a follow up.
> 

I don't have any objection or other comment on that series. So
basically, I'm waiting for v3 and I'll apply it.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  parent reply	other threads:[~2016-01-25 16:25 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-21 20:23 [rtc-linux] [PATCH v2 00/10] rtc: max77686: Extend driver and add max77802 support Javier Martinez Canillas
2016-01-21 20:23 ` Javier Martinez Canillas
2016-01-21 20:23 ` Javier Martinez Canillas
2016-01-21 20:23 ` [rtc-linux] [PATCH v2 01/10] rtc: max77686: Fix max77686_rtc_read_alarm() return value Javier Martinez Canillas
2016-01-21 20:23   ` Javier Martinez Canillas
2016-01-22  0:51   ` [rtc-linux] " Krzysztof Kozlowski
2016-01-22  0:51     ` Krzysztof Kozlowski
2016-01-22  9:35   ` [rtc-linux] " Laxman Dewangan
2016-01-22  9:35     ` Laxman Dewangan
2016-01-22  9:35     ` Laxman Dewangan
2016-01-21 20:23 ` [rtc-linux] [PATCH v2 02/10] rtc: max77686: Use ARRAY_SIZE() instead of current array length Javier Martinez Canillas
2016-01-21 20:23   ` Javier Martinez Canillas
2016-01-22  0:53   ` [rtc-linux] " Krzysztof Kozlowski
2016-01-22  0:53     ` Krzysztof Kozlowski
2016-01-22  9:39   ` [rtc-linux] " Laxman Dewangan
2016-01-22  9:39     ` Laxman Dewangan
2016-01-22  9:39     ` Laxman Dewangan
2016-01-22 11:43     ` [rtc-linux] " Javier Martinez Canillas
2016-01-22 11:43       ` Javier Martinez Canillas
2016-01-21 20:23 ` [rtc-linux] [PATCH v2 03/10] rtc: max77686: Use usleep_range() instead of msleep() Javier Martinez Canillas
2016-01-21 20:23   ` Javier Martinez Canillas
2016-01-22  1:02   ` [rtc-linux] " Krzysztof Kozlowski
2016-01-22  1:02     ` Krzysztof Kozlowski
2016-01-22  9:41   ` [rtc-linux] " Laxman Dewangan
2016-01-22  9:41     ` Laxman Dewangan
2016-01-22  9:41     ` Laxman Dewangan
2016-01-22 12:05     ` [rtc-linux] " Javier Martinez Canillas
2016-01-22 12:05       ` Javier Martinez Canillas
2016-01-25 11:17       ` [rtc-linux] " Laxman Dewangan
2016-01-25 11:17         ` Laxman Dewangan
2016-01-25 11:17         ` Laxman Dewangan
2016-01-21 20:23 ` [rtc-linux] [PATCH v2 04/10] rtc: max77686: Use a driver data struct instead hard-coded values Javier Martinez Canillas
2016-01-21 20:23   ` Javier Martinez Canillas
2016-01-22  1:00   ` [rtc-linux] " Krzysztof Kozlowski
2016-01-22  1:00     ` Krzysztof Kozlowski
2016-01-22  1:48     ` [rtc-linux] " Javier Martinez Canillas
2016-01-22  1:48       ` Javier Martinez Canillas
2016-01-22  9:50   ` [rtc-linux] " Laxman Dewangan
2016-01-22  9:50     ` Laxman Dewangan
2016-01-22  9:50     ` Laxman Dewangan
2016-01-21 20:23 ` [rtc-linux] [PATCH v2 05/10] rtc: max77686: Add an indirection level to access RTC registers Javier Martinez Canillas
2016-01-21 20:23   ` Javier Martinez Canillas
2016-01-22  9:52   ` [rtc-linux] " Laxman Dewangan
2016-01-22  9:52     ` Laxman Dewangan
2016-01-22  9:52     ` Laxman Dewangan
2016-01-21 20:23 ` [rtc-linux] [PATCH v2 06/10] rtc: max77686: Add max77802 support Javier Martinez Canillas
2016-01-21 20:23   ` Javier Martinez Canillas
2016-01-22  9:54   ` [rtc-linux] " Laxman Dewangan
2016-01-22  9:54     ` Laxman Dewangan
2016-01-22  9:54     ` Laxman Dewangan
2016-01-21 20:23 ` [rtc-linux] [PATCH v2 07/10] rtc: max77686: Use dev_warn() instead of pr_warn() Javier Martinez Canillas
2016-01-21 20:23   ` Javier Martinez Canillas
2016-01-22  9:56   ` [rtc-linux] " Laxman Dewangan
2016-01-22  9:56     ` Laxman Dewangan
2016-01-22  9:56     ` Laxman Dewangan
2016-01-21 20:23 ` [rtc-linux] [PATCH v2 08/10] rtc: Remove Maxim 77802 driver Javier Martinez Canillas
2016-01-21 20:23   ` Javier Martinez Canillas
2016-01-22  9:59   ` [rtc-linux] " Laxman Dewangan
2016-01-22  9:59     ` Laxman Dewangan
2016-01-22  9:59     ` Laxman Dewangan
2016-01-21 20:23 ` [rtc-linux] [PATCH v2 09/10] ARM: exynos_defconfig: Remove MAX77802 RTC Kconfig symbol Javier Martinez Canillas
2016-01-21 20:23   ` Javier Martinez Canillas
2016-01-21 20:23 ` [rtc-linux] [PATCH v2 10/10] ARM: multi_v7_defconfig: " Javier Martinez Canillas
2016-01-21 20:23   ` Javier Martinez Canillas
2016-01-21 20:23   ` Javier Martinez Canillas
2016-01-22  9:57   ` [rtc-linux] " Laxman Dewangan
2016-01-22  9:57     ` Laxman Dewangan
2016-01-22  9:57     ` Laxman Dewangan
2016-01-22  9:57     ` Laxman Dewangan
2016-01-22 12:09     ` [rtc-linux] " Javier Martinez Canillas
2016-01-22 12:09       ` Javier Martinez Canillas
2016-01-22 12:09       ` Javier Martinez Canillas
2016-01-25 16:06 ` Alexandre Belloni [this message]
2016-01-25 16:06   ` [PATCH v2 00/10] rtc: max77686: Extend driver and add max77802 support Alexandre Belloni
2016-01-25 16:06   ` Alexandre Belloni
2016-01-25 23:45   ` [rtc-linux] " Javier Martinez Canillas
2016-01-25 23:45     ` Javier Martinez Canillas
2016-01-25 23:45     ` Javier Martinez Canillas

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=20160125160633.GB11740@piout.net \
    --to=alexandre.belloni@free-electrons.com \
    --cc=arnd@arndb.de \
    --cc=cw00.choi@samsung.com \
    --cc=javier@osg.samsung.com \
    --cc=k.kozlowski@samsung.com \
    --cc=kgene@kernel.org \
    --cc=ldewangan@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=olof@lixom.net \
    --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.