linux-watchdog.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: "lee.jones@linaro.org" <lee.jones@linaro.org>
Cc: "linux@roeck-us.net" <linux@roeck-us.net>,
	"wim@linux-watchdog.org" <wim@linux-watchdog.org>,
	"mazziesaccount@gmail.com" <mazziesaccount@gmail.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linux-power <linux-power@fi.rohmeurope.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>
Subject: Re: [PATCH RESEND v6 2/4] mfd: Support ROHM BD9576MUF and BD9573MUF
Date: Fri, 27 Nov 2020 09:44:08 +0000	[thread overview]
Message-ID: <6bd4abcb340bdf764fd23b685684d3f984319ed7.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <20201127083242.GK2455276@dell>

Hello Lee,

On Fri, 2020-11-27 at 08:32 +0000, Lee Jones wrote:
> On Mon, 23 Nov 2020, Matti Vaittinen wrote:
> 
> > Add core support for ROHM BD9576MUF and BD9573MUF PMICs which are
> > mainly used to power the R-Car series processors.
> > 
> > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> > ---
> >  drivers/mfd/Kconfig              |  11 ++++
> >  drivers/mfd/Makefile             |   1 +
> >  drivers/mfd/rohm-bd9576.c        | 108
> > +++++++++++++++++++++++++++++++
> >  include/linux/mfd/rohm-bd957x.h  |  59 +++++++++++++++++
> >  include/linux/mfd/rohm-generic.h |   2 +
> >  5 files changed, 181 insertions(+)
> >  create mode 100644 drivers/mfd/rohm-bd9576.c
> >  create mode 100644 include/linux/mfd/rohm-bd957x.h
> 
> Looks like a possible candidate for "simple-mfd-i2c".
> 
> Could you look into that please?
> 
I must admit I didn't know about "simple-mfd-i2c". Good thing to know
when working with simple devices :) Is this a new thing?
I am unsure I understand the idea fully. Should users put all the
different regamp configs in this file and just add the device IDs with
pointer to correct config? (BD9576 and BD9573 need volatile ranges).
Also, does this mean each sub-device should have own node and own
compatible in DT to get correctly load and probed? I guess this would
need a buy-in from Rob too then.

By the way - for uneducated eyes like mine this does not look like it
has much to do with MFD as a device - here MFD reminds me of a simple-
bus on top of I2C.

Anyways, the BD9576 and BD9573 both have a few interrupts for OVD/UVD
conditions and I am expecting that I will be asked to provide the
regulator notifiers for those. Reason why I omitted the IRQs for now is
that the HW is designed to keep the IRQ asserted for whole error
duration so some delayed ack mechanism would be needed. I would like to
keep the door open for adding IRQs to MFD core.

Best Regards
	Matti

  reply	other threads:[~2020-11-27  9:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-23  6:19 [PATCH RESEND v6 0/4] Support ROHM BD9576MUF and BD9573MUF PMICs Matti Vaittinen
2020-11-23  6:20 ` [PATCH RESEND v6 1/4] dt_bindings: mfd: Add " Matti Vaittinen
2020-11-23  6:20 ` [PATCH RESEND v6 2/4] mfd: Support ROHM BD9576MUF and BD9573MUF Matti Vaittinen
2020-11-27  8:32   ` Lee Jones
2020-11-27  9:44     ` Vaittinen, Matti [this message]
2020-12-02 12:57       ` Lee Jones
2020-12-02 13:32         ` Vaittinen, Matti
2020-12-17 10:04           ` Vaittinen, Matti
2020-12-29  8:43             ` Vaittinen, Matti
2021-01-14 10:00               ` Lee Jones
2021-01-14 10:57                 ` Vaittinen, Matti
2020-12-02 14:26         ` Vaittinen, Matti
2020-11-23  6:21 ` [PATCH RESEND v6 3/4] wdt: Support wdt on " Matti Vaittinen
2020-11-23  6:21 ` [PATCH RESEND v6 4/4] MAINTAINERS: Add ROHM BD9576MUF and BD9573MUF drivers 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=6bd4abcb340bdf764fd23b685684d3f984319ed7.camel@fi.rohmeurope.com \
    --to=matti.vaittinen@fi.rohmeurope.com \
    --cc=devicetree@vger.kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-power@fi.rohmeurope.com \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mazziesaccount@gmail.com \
    --cc=robh+dt@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).