From: Jonathan Cameron <jic23@kernel.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: saravanan sekar <sravanhome@gmail.com>,
robh+dt@kernel.org, knaack.h@gmx.de, lars@metafoo.de,
pmeerw@pmeerw.net, sre@kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
linux-pm@vger.kernel.org
Subject: Re: [PATCH v4 2/5] mfd: mp2629: Add support for mps battery charger
Date: Sat, 28 Mar 2020 14:36:49 +0000 [thread overview]
Message-ID: <20200328143649.2a428bee@archlinux> (raw)
In-Reply-To: <20200327102221.GA3383@dell>
On Fri, 27 Mar 2020 10:22:21 +0000
Lee Jones <lee.jones@linaro.org> wrote:
> Saravanan, Jonathan,
>
> On Fri, 27 Mar 2020, saravanan sekar wrote:
> > On 27/03/20 8:55 am, Lee Jones wrote:
> > > On Sun, 22 Mar 2020, Saravanan Sekar wrote:
> > >
> > > > mp2629 is a highly-integrated switching-mode battery charge management
> > > > device for single-cell Li-ion or Li-polymer battery.
> > > >
> > > > Add MFD core enables chip access for ADC driver for battery readings,
> > > > and a power supply battery-charger driver
> > > >
> > > > Signed-off-by: Saravanan Sekar <sravanhome@gmail.com>
> > > > ---
> > > > drivers/mfd/Kconfig | 9 +++
> > > > drivers/mfd/Makefile | 2 +
> > > > drivers/mfd/mp2629.c | 116 +++++++++++++++++++++++++++++++++++++
> > > > include/linux/mfd/mp2629.h | 22 +++++++
> > > > 4 files changed, 149 insertions(+)
> > > > create mode 100644 drivers/mfd/mp2629.c
> > > > create mode 100644 include/linux/mfd/mp2629.h
>
> [...]
>
> > > > +static int mp2629_probe(struct i2c_client *client)
> > > > +{
> > > > + struct mp2629_info *info;
> > > Call this ddata instead of info.
> > Not sure the reason, I will do.
>
> Because this is device data. Info is too loose of a definition.
>
> > > > + struct resource *resources;
> > > > + int ret;
> > > > + int i;
> > > > +
> > > > + info = devm_kzalloc(&client->dev, sizeof(*info), GFP_KERNEL);
> > > > + if (!info)
> > > > + return -ENOMEM;
> > > > +
> > > > + info->dev = &client->dev;
> > > > + i2c_set_clientdata(client, info);
> > > > +
> > > > + info->regmap = devm_regmap_init_i2c(client, &mp2629_regmap_config);
> > > > + if (IS_ERR(info->regmap)) {
> > > > + dev_err(info->dev, "Failed to allocate regmap!\n");
> > > > + return PTR_ERR(info->regmap);
> > > > + }
> > > > +
> > > > + for (i = 0; i < MP2629_MFD_MAX; i++) {
> > > > + mp2629mfd[i].platform_data = &info->regmap;
> > > > + mp2629mfd[i].pdata_size = sizeof(info->regmap);
> > > You don't need to store this in platform data as well.
> > >
> > > You already have it in device data (ddata [currently 'info']).
> >
> > "The IIO parts seems fine (minor comments inline) but I'm not keep on
> > directly accessing the internals of the mfd device info structure.
> > To my mind that should be opaque to the child drivers so as to provide
> > clear structure to any such accesses.
> >
> > This mess in layering with the children directly using the parents
> > regmap is a little concerning. It means that the 3 drivers
> > really aren't very well separated and can't really be reviewed
> > independently (not a good thing)."
> >
> > This is the review comments form Jonathan on V2, not to access parent data
> > structure directly.
> > Am I misunderstood his review comments? please suggest the better option to
> > follow as like in V2
> > or V2 + some improvements or V4 + improvements?
>
> I will take this up with Jonathan separately if necessary.
>
> For your FYI (and Jonathan if he's Cc'ed), it's very common for a
> child of an MFD to acquire resources from their parent. That is the
> point of a lot of MFDs, to obtain and register shared resources and
> pass them onto their offspring. There are 10's of examples of this.
>
> Things like Regmaps aren't platform data, they are device/driver data,
> which is usually passed though platform_set_drvdata().
>
Fair enough. It seemed a bit messy to have full visibility of the
parent driver structures just to access one element.
What I was actually meaning to suggest was a couple of wrapper functions,
not passing the regmap separately, but I guess that doesn't really make
any difference.
So a read / write wrapper that just takes an abstract ddata pointer.
Fair enough if you think that's an unnecessary bit of abstraction.
Jonathan
> [...]
>
> > > > + */
> > > > +
> > > > +#ifndef __MP2629_H__
> > > > +#define __MP2629_H__
> > > > +
> > > > +#include <linux/types.h>
> > > > +
> > > > +struct device;
> > > > +struct regmap;
> > > Why not just add the includes?
> > Some more shared enum added in ADC driver
>
> Sorry?
>
> > > > +struct mp2629_info {
> > > > + struct device *dev;
> > > > + struct regmap *regmap;
> > > > +};
> > > > +
> > > > +#endif
>
next prev parent reply other threads:[~2020-03-28 14:36 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-22 22:46 [PATCH v4 0/5] Add battery charger driver support for MP2629 Saravanan Sekar
2020-03-22 22:46 ` [PATCH v4 1/5] dt-bindings: mfd: add document bindings for mp2629 Saravanan Sekar
2020-03-27 8:00 ` Lee Jones
2020-03-27 21:50 ` saravanan sekar
2020-03-30 6:46 ` Lee Jones
2020-04-07 16:29 ` saravanan sekar
2020-04-08 10:15 ` Lee Jones
2020-03-22 22:46 ` [PATCH v4 2/5] mfd: mp2629: Add support for mps battery charger Saravanan Sekar
2020-03-27 7:55 ` Lee Jones
2020-03-27 8:32 ` saravanan sekar
2020-03-27 10:22 ` Lee Jones
2020-03-27 10:56 ` saravanan sekar
2020-03-27 11:25 ` Lee Jones
2020-03-27 12:40 ` saravanan sekar
2020-03-27 12:56 ` Andy Shevchenko
2020-03-27 13:03 ` saravanan sekar
2020-03-27 13:17 ` Andy Shevchenko
2020-03-28 14:36 ` Jonathan Cameron [this message]
2020-03-22 22:46 ` [PATCH v4 3/5] iio: adc: mp2629: Add support for mp2629 ADC driver Saravanan Sekar
2020-03-22 23:32 ` Andy Shevchenko
2020-03-28 14:42 ` Jonathan Cameron
2020-03-28 18:50 ` Andy Shevchenko
2020-03-29 10:37 ` saravanan sekar
2020-03-29 11:09 ` Andy Shevchenko
2020-03-22 22:46 ` [PATCH v4 4/5] power: supply: Add support for mps mp2629 battery charger Saravanan Sekar
2020-03-22 23:26 ` Andy Shevchenko
2020-03-23 12:29 ` saravanan sekar
2020-03-22 22:46 ` [PATCH v4 5/5] MAINTAINERS: Add entry for mp2629 Battery Charger driver Saravanan Sekar
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=20200328143649.2a428bee@archlinux \
--to=jic23@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=lee.jones@linaro.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
--cc=robh+dt@kernel.org \
--cc=sravanhome@gmail.com \
--cc=sre@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
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).