From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com> To: "alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com> Cc: "dmurphy@ti.com" <dmurphy@ti.com>, "linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>, "linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>, "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "mazziesaccount@gmail.com" <mazziesaccount@gmail.com>, "mturquette@baylibre.com" <mturquette@baylibre.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "jacek.anaszewski@gmail.com" <jacek.anaszewski@gmail.com>, "a.zummo@towertech.it" <a.zummo@towertech.it>, "linus.walleij@linaro.org" <linus.walleij@linaro.org>, "lgirdwood@gmail.com" <lgirdwood@gmail.com>, "mark.rutland@arm.com" <mark.rutland@arm.com>, "robh+dt@kernel.org" <robh+dt@kernel.org>, "bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>, "linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>, "pavel@ucw.cz" <pavel@ucw.cz>, "sboyd@kernel.org" <sboyd@kernel.org>, "broonie@kernel.org" <broonie@kernel.org>, "lee.jones@linaro.org" <lee.jones@linaro.org> Subject: Re: [RFC PATCH 09/13] mfd: rtc: support RTC on ROHM BD71828 with BD70528 driver Date: Tue, 29 Oct 2019 14:08:58 +0000 Message-ID: <144bc58e8fbb350e3a1810654dea9427a86460be.camel@fi.rohmeurope.com> (raw) In-Reply-To: <20191029135021.GC11234@piout.net> On Tue, 2019-10-29 at 14:50 +0100, Alexandre Belloni wrote: > On 23/10/2019 10:27:43+0000, Vaittinen, Matti wrote: > > Hello again Alexandre, > > > > On Thu, 2019-10-17 at 12:48 +0200, Alexandre Belloni wrote: > > > On 17/10/2019 10:36:44+0000, Vaittinen, Matti wrote: > > > > Hello Alexandre, > > > > > > > > Thanks for quick check! I'll be off for the rest of the week > > > > but I > > > > will > > > > re-work this patch at next week :) I agree with you regarding > > > > most > > > > of > > > > the comments. > > > > > > > > > > + > > > > > > + > > > > > > +/* > > > > > > + * RTC definitions shared between > > > > > > + * > > > > > > + * BD70528 > > > > > > + * and BD71828 > > > > > > + */ > > > > > > + > > > > > > +#define ROHM_BD1_MASK_RTC_SEC 0x7f > > > > > > +#define ROHM_BD1_MASK_RTC_MINUTE 0x7f > > > > > > +#define ROHM_BD1_MASK_RTC_HOUR_24H 0x80 > > > > > > +#define ROHM_BD1_MASK_RTC_HOUR_PM 0x20 > > > > > > +#define ROHM_BD1_MASK_RTC_HOUR 0x3f > > > > > > +#define ROHM_BD1_MASK_RTC_DAY 0x3f > > > > > > +#define ROHM_BD1_MASK_RTC_WEEK 0x07 > > > > > > +#define ROHM_BD1_MASK_RTC_MONTH 0x1f > > > > > > +#define ROHM_BD1_MASK_RTC_YEAR 0xff > > > > > > +#define ROHM_BD1_MASK_ALM_EN 0x7 > > > > > > + > > > > > > > > > > All that renaming is distracting and useless. Please resubmit > > > > > without > > > > > renaming defines, structs and functions to make it easier to > > > > > review. > > > > > > > > I would prefer renaming because it makes it clearly visible > > > > which > > > > defines/structs/functions are common for both PMICs and which > > > > are > > > > PMIC > > > > specific. But I really understand the problem of spotting real > > > > changes. > > > > Would it be Ok if I did renaming in separate patch which does > > > > not > > > > bring > > > > in any other changes - and then the functional changes in > > > > separate > > > > patch? > > > > > > > > > > No, unless you can guarantee that all future PMICs from rohm > > > matching > > > the wildcard will use this driver. > > > > > I started re-working this patch and remembered my original idea > > regarding the naming :) I should have commented it as I had already > > forgotten it. You are correct what comes to the difficulty of using > > correct wild-cards. And I agree with you what comes to function and > > struct names like bd7xx28 - those are somewhat fragile as next PMIC > > which we want to support with this driver may be BD12345 - yielding > > our > > wild-card useless. > > > > But if we take a look of common definitions in header rohm-shared.h > > which I added - those are prefixed as ROHM_BD1. My idea was > > introducing > > this common RTC define group 1 - which would be common define group > > for > > all devices which belong to BD1 group. Currently that would be > > BD71828 > > and BD70528. What was missing is the comment explaining this (and > > lack > > of comment made this useless as even I forgot it already). > > > > I already reverted this naming change and all BD70528 specific and > > common defines/functions/enums are prefixed with the good old > > BD70528. > > Only new definitions which I added for BD71828 are prefixed with > > BD71828. But how do you see the grouping the common defines to > > format > > ROHM_BD<group number>_FOO_BAR in the rohm-shared.h - with comment > > that > > group BD1 consists of definitions which are common for BD70528 and > > BD71828? > > > > My only fear when using prefix BD70528 for common defines is that > > someone changes some defines to match the BD70528 data-sheet > > without > > evaluating if this impacts to other PMICs. It may be useless > > paranoia > > though - hence I am asking for your opinion at this phase. I can do > > this grouping in own patch - or just leave it as it is now in my > > local > > repo - with the old BD70528 being common prefix. > > > > I don't think those masks will ever change, all the BCD RTCs are > using > the same. I guess this is very true. And to follow this further - If then next ROHM RTC I work with is not using BCD - then I am probably not trying to support it with this driver. So I'd say you are correct. > Note that ROHM_BD1_MASK_RTC_HOUR_24H, ROHM_BD1_MASK_RTC_HOUR_PM and > ROHM_BD1_MASK_ALM_EN are bits and should use BIT() to make that > clear. Ok. I'll use BIT() for new/moved one bit defines in next versions. > Those may change later but I don't see how someone looking at the > BD70528 datasheet would get those wrong. I admit this is unlikely and I don't see the scenario how this can break - assuming these masks are now correct for BD70528 ;) If there was an error then having prefix BD70528 for define which is used by BD71828 (and possibly others) might be error prone as one could fix the define without checking the BD71828. When we limit this to those three defines it is _really_ unlikely (and probably not a problem) - but this was the reason why I wanted to do the renaming of common defines. By the way, I sent patch v2 couple of days ago - and I kept the BD70528 prefix as you suggested. I'll do that also in next versions so we can probably say this case is closed :] Thanks for taking the time to read the patches! Br, Matti Vaittinen
next prev parent reply index Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-17 9:40 [RFC PATCH 00/13] Support ROHM BD71828 PMIC Matti Vaittinen 2019-10-17 9:41 ` [RFC PATCH 01/13] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen 2019-10-17 9:42 ` [RFC PATCH 02/13] mfd: input: bd71828: Add power-key support Matti Vaittinen 2019-10-17 9:43 ` [RFC PATCH 03/13] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen 2019-10-17 9:44 ` [RFC PATCH 04/13] regulator: bd718x7: Split driver to common and bd718x7 specific parts Matti Vaittinen 2019-10-17 9:44 ` [RFC PATCH 05/13] regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators Matti Vaittinen 2019-10-17 9:48 ` [RFC PATCH 06/13] regulator: bd71828: Add GPIO based run-level control for regulators Matti Vaittinen 2019-10-17 9:50 ` [RFC PATCH 07/13] regulator: bd71828: enhanced run-level support Matti Vaittinen 2019-10-17 9:51 ` [RFC PATCH 08/13] regulator: bd71828: Support in-kernel APIs to change run-level Matti Vaittinen 2019-10-17 9:52 ` [RFC PATCH 09/13] mfd: rtc: support RTC on ROHM BD71828 with BD70528 driver Matti Vaittinen 2019-10-17 10:12 ` Alexandre Belloni 2019-10-17 10:36 ` Vaittinen, Matti 2019-10-17 10:48 ` Alexandre Belloni 2019-10-21 5:29 ` Vaittinen, Matti 2019-10-23 10:27 ` Vaittinen, Matti 2019-10-29 13:50 ` Alexandre Belloni 2019-10-29 14:08 ` Vaittinen, Matti [this message] 2019-10-17 9:53 ` [RFC PATCH 10/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen 2019-10-17 12:45 ` Bartosz Golaszewski 2019-10-21 7:00 ` Vaittinen, Matti 2019-10-21 14:36 ` Bartosz Golaszewski 2019-10-21 14:56 ` Vaittinen, Matti 2019-10-22 13:19 ` Vaittinen, Matti 2019-10-17 9:53 ` [RFC PATCH 11/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC Matti Vaittinen 2019-10-17 14:04 ` Dan Murphy 2019-10-17 14:28 ` Alexandre Belloni 2019-10-21 8:00 ` Vaittinen, Matti 2019-10-21 19:09 ` Jacek Anaszewski 2019-10-22 12:40 ` Vaittinen, Matti 2019-10-22 17:40 ` Jacek Anaszewski 2019-10-23 8:37 ` Vaittinen, Matti 2019-10-23 21:59 ` Jacek Anaszewski 2019-10-24 8:15 ` Vaittinen, Matti 2019-10-24 22:04 ` Jacek Anaszewski 2019-10-25 7:07 ` Vaittinen, Matti 2019-10-25 13:24 ` Rob Herring 2019-10-25 14:37 ` Vaittinen, Matti 2019-10-25 15:47 ` Rob Herring 2019-10-29 13:29 ` Vaittinen, Matti 2019-10-17 9:55 ` [RFC PATCH 12/13] dt-bindings: mfd: Document ROHM BD71282 bindings Matti Vaittinen 2019-10-17 14:18 ` Dan Murphy 2019-10-21 8:03 ` Vaittinen, Matti 2019-10-17 9:57 ` [RFC PATCH 13/13] dt-bindings: regulator: Document ROHM BD71282 regulator bindings Matti Vaittinen
Reply instructions: You may reply publically 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=144bc58e8fbb350e3a1810654dea9427a86460be.camel@fi.rohmeurope.com \ --to=matti.vaittinen@fi.rohmeurope.com \ --cc=a.zummo@towertech.it \ --cc=alexandre.belloni@bootlin.com \ --cc=bgolaszewski@baylibre.com \ --cc=broonie@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=dmurphy@ti.com \ --cc=jacek.anaszewski@gmail.com \ --cc=lee.jones@linaro.org \ --cc=lgirdwood@gmail.com \ --cc=linus.walleij@linaro.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-leds@vger.kernel.org \ --cc=linux-rtc@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=mazziesaccount@gmail.com \ --cc=mturquette@baylibre.com \ --cc=pavel@ucw.cz \ --cc=robh+dt@kernel.org \ --cc=sboyd@kernel.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
Linux-RTC Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-rtc/0 linux-rtc/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-rtc linux-rtc/ https://lore.kernel.org/linux-rtc \ linux-rtc@vger.kernel.org public-inbox-index linux-rtc Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-rtc AGPL code for this site: git clone https://public-inbox.org/public-inbox.git