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
next prev parent reply other threads:[~2016-01-25 16:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-21 20:23 [PATCH v2 00/10] rtc: max77686: Extend driver and add max77802 support Javier Martinez Canillas
2016-01-21 20:23 ` [PATCH v2 10/10] ARM: multi_v7_defconfig: Remove MAX77802 RTC Kconfig symbol Javier Martinez Canillas
2016-01-22 9:57 ` Laxman Dewangan
2016-01-22 12:09 ` Javier Martinez Canillas
2016-01-25 16:06 ` Alexandre Belloni [this message]
2016-01-25 23:45 ` [PATCH v2 00/10] rtc: max77686: Extend driver and add max77802 support 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=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).