From: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: Matti Vaittinen <mazziesaccount@gmail.com>,
Guenter Roeck <linux@roeck-us.net>,
heikki.haikola@fi.rohmeurope.com,
mikko.mutanen@fi.rohmeurope.com, robh+dt@kernel.org,
mark.rutland@arm.com, broonie@kernel.org,
gregkh@linuxfoundation.org, rafael@kernel.org,
mturquette@baylibre.com, sboyd@kernel.org,
linus.walleij@linaro.org, bgolaszewski@baylibre.com,
sre@kernel.org, lgirdwood@gmail.com, a.zummo@towertech.it,
alexandre.belloni@bootlin.com, wim@linux-watchdog.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-pm@vger.kernel.org, linux-rtc@vger.kernel.org,
linux-watchdog@vger.kernel.org
Subject: Re: [PATCH v8 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
Date: Tue, 12 Feb 2019 11:37:59 +0200 [thread overview]
Message-ID: <20190212093759.GA12247@localhost.localdomain> (raw)
In-Reply-To: <20190212091723.GZ20638@dell>
Thanks Again Lee,
On Tue, Feb 12, 2019 at 09:17:23AM +0000, Lee Jones wrote:
> On Fri, 08 Feb 2019, Matti Vaittinen wrote:
>
> > > I think an exported function with comments would be better.
> > So do you mean you would prefer exported function over the pointer from
> Yes please. Call-back pointers for non-subsystem level actions are a
> bit messy IMHO.
That's fine. I'll go with exported function then =)
> > case it just hides the meaning of values we are passing as arguments.
> > With raw assignment we at least have some idea what the 0x40 or 0x20 are
> > referring to =)
>
> Well I do agree with your last comment.
>
> Maybe doing the following would help with the ugliness (i.e. the shear
> number of chars):
>
> unsigned int type_reg_offset_inc = 0;
> for (i = BD70528_INT_GPIO0; i <= BD70528_INT_GPIO3; i++) {
> <blar> *t = irqs[i].type;
> t->type_reg_offset = type_reg_offset_inc;
> t->type_rising_val = 0x20;
> t->type_falling_val = 0x10;
> t->type_level_high_val = 0x40;
> t->type_level_low_val = 0x50;
> t->types_supported =
> (IRQ_TYPE_EDGE_BOTH | IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW);
> type_reg_offset_inc += 2;
> }
I'll go with this for next version.
> > > > > > + /* wdt_set must be called rtc_timer_lock held */
> > > > >
> > > > > This doesn't make sense.
> > > >
> > > > Umm.. The comment does not make sense? Maybe I can explain it further.
> > >
> > > "wdt_set must be called when the rtc_timer_lock is held"
> >
> > Yes. I wanted to say that who-ever is calling the wdt_set function
> > below, should have locked the rtc_timer_lock mutex (last in this
> > struct). The function does not do locking inside because we want the RTC
> > to be able to perform:
> >
> > lock
> > disable wdt (store original state)
> > set RTC
> > return wdt original state
> > unlock
> >
> > Locking is needed so that we can exclude the watchdog enabling or
> > disabling the WDT timer between moments when RTC is getting the original
> > WDT state and re-turning back the old state. Without the lock we have a
> > risk that WDT-driver enables or disables the timer when RTC is being
> > set, and RTC overwrites the watchdog driver changes when writing back
> > the old state. I hope this makes sense now... Any suggestions how to
> > explain this nicely in english?
>
> I think I did already:
>
> "wdt_set must be called when the rtc_timer_lock is held"
>
> Actually, this is a little ambiguous. A better sentence could read:
>
> "rtc_timer_lock must be taken before calling wdt_set()"
Sure. I'll ruthlessy plagiarize that sentence. (And as I am not at all
sure if "ruthlessy plagiarize" actually means what I think it does -
I tried to say that I'll take your suggestion and use it :] )
Once again, thanks for the help =)
Br,
Matti
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then, he vanished ~~~
next prev parent reply other threads:[~2019-02-12 9:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-07 7:27 [PATCH v8 0/8] support ROHM BD70528 PMIC Matti Vaittinen
2019-02-07 7:34 ` [PATCH v8 1/8] mfd: regulator: clk: split rohm-bd718x7.h Matti Vaittinen
2019-02-07 11:41 ` Lee Jones
2019-02-07 7:35 ` [PATCH v8 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core Matti Vaittinen
2019-02-07 14:00 ` Lee Jones
2019-02-07 16:28 ` Matti Vaittinen
2019-02-08 10:57 ` Lee Jones
2019-02-08 12:41 ` Matti Vaittinen
2019-02-12 9:17 ` Lee Jones
2019-02-12 9:37 ` Matti Vaittinen [this message]
2019-02-08 7:30 ` Matti Vaittinen
2019-02-07 7:36 ` [PATCH v8 3/8] clk: bd718x7: Support ROHM BD70528 clk block Matti Vaittinen
2019-02-07 7:37 ` [PATCH v8 4/8] devicetree: bindings: Document first ROHM BD70528 bindings Matti Vaittinen
2019-02-07 14:04 ` Lee Jones
2019-02-07 15:36 ` Matti Vaittinen
2019-02-07 15:42 ` Guenter Roeck
2019-02-07 16:33 ` Matti Vaittinen
2019-02-07 7:38 ` [PATCH v8 5/8] gpio: Initial support for ROHM bd70528 GPIO block Matti Vaittinen
2019-02-07 7:39 ` [PATCH v8 6/8] rtc: bd70528: Initial support for ROHM bd70528 RTC Matti Vaittinen
2019-02-07 7:40 ` [PATCH v8 7/8] power: supply: Initial support for ROHM BD70528 PMIC charger block Matti Vaittinen
2019-02-07 7:42 ` [PATCH v8 8/8] watchdog: bd70528: Initial support for ROHM BD70528 watchdog block Matti Vaittinen
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=20190212093759.GA12247@localhost.localdomain \
--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=gregkh@linuxfoundation.org \
--cc=heikki.haikola@fi.rohmeurope.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-pm@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mark.rutland@arm.com \
--cc=mazziesaccount@gmail.com \
--cc=mikko.mutanen@fi.rohmeurope.com \
--cc=mturquette@baylibre.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=sre@kernel.org \
--cc=wim@linux-watchdog.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).