From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.free-electrons.com (down.free-electrons.com. [37.187.137.238]) by gmr-mx.google.com with ESMTP id b4si377993wme.3.2016.01.25.08.25.03 for ; Mon, 25 Jan 2016 08:25:03 -0800 (PST) Date: Mon, 25 Jan 2016 17:06:33 +0100 From: Alexandre Belloni To: Javier Martinez Canillas Cc: linux-kernel@vger.kernel.org, Kukjin Kim , rtc-linux@googlegroups.com, Chanwoo Choi , Krzysztof Kozlowski , Laxman Dewangan , linux-samsung-soc@vger.kernel.org, Arnd Bergmann , Olof Johansson , linux-arm-kernel@lists.infradead.org Subject: [rtc-linux] Re: [PATCH v2 00/10] rtc: max77686: Extend driver and add max77802 support Message-ID: <20160125160633.GB11740@piout.net> References: <1453407813-14646-1-git-send-email-javier@osg.samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 In-Reply-To: <1453407813-14646-1-git-send-email-javier@osg.samsung.com> Reply-To: rtc-linux@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexandre Belloni Subject: Re: [PATCH v2 00/10] rtc: max77686: Extend driver and add max77802 support Date: Mon, 25 Jan 2016 17:06:33 +0100 Message-ID: <20160125160633.GB11740@piout.net> References: <1453407813-14646-1-git-send-email-javier@osg.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from down.free-electrons.com ([37.187.137.238]:60826 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756455AbcAYQZE (ORCPT ); Mon, 25 Jan 2016 11:25:04 -0500 Content-Disposition: inline In-Reply-To: <1453407813-14646-1-git-send-email-javier@osg.samsung.com> Sender: linux-samsung-soc-owner@vger.kernel.org List-Id: linux-samsung-soc@vger.kernel.org To: Javier Martinez Canillas Cc: linux-kernel@vger.kernel.org, Kukjin Kim , rtc-linux@googlegroups.com, Chanwoo Choi , Krzysztof Kozlowski , Laxman Dewangan , linux-samsung-soc@vger.kernel.org, Arnd Bergmann , Olof Johansson , linux-arm-kernel@lists.infradead.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: alexandre.belloni@free-electrons.com (Alexandre Belloni) Date: Mon, 25 Jan 2016 17:06:33 +0100 Subject: [PATCH v2 00/10] rtc: max77686: Extend driver and add max77802 support In-Reply-To: <1453407813-14646-1-git-send-email-javier@osg.samsung.com> References: <1453407813-14646-1-git-send-email-javier@osg.samsung.com> Message-ID: <20160125160633.GB11740@piout.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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