All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>, Sebastian Reichel <sre@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	DTML <devicetree@vger.kernel.org>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
	Linux LED Subsystem <linux-leds@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH 12/13] input: max77650: add onkey support
Date: Thu, 14 Feb 2019 09:42:48 +0000	[thread overview]
Message-ID: <20190214094248.GI13737@dell> (raw)
In-Reply-To: <CAKdAkRQZ+ug7tpkE4x_8iTbUm9JnyF5wWrUnPRASi98t25LTbA@mail.gmail.com>

On Tue, 12 Feb 2019, Dmitry Torokhov wrote:

> Hi Lee,
> 
> On Tue, Feb 12, 2019 at 12:34 PM Lee Jones <lee.jones@linaro.org> wrote:
> >
> > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > > >
> > > > Add support for the push- and slide-button events for max77650.
> > > >
> > > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > > > ---
> > > >  drivers/input/misc/Kconfig          |   9 ++
> > > >  drivers/input/misc/Makefile         |   1 +
> > > >  drivers/input/misc/max77650-onkey.c | 135 ++++++++++++++++++++++++++++
> > > >  3 files changed, 145 insertions(+)
> > > >  create mode 100644 drivers/input/misc/max77650-onkey.c
> >
> > [...]
> >
> > Moving things around a bit:
> >
> > > > +static int max77650_onkey_probe(struct platform_device *pdev)
> > > > +{
> >
> > > > +   irq_f = regmap_irq_get_virq(irq_data, MAX77650_INT_nEN_F);
> > > > +   if (irq_f <= 0)
> > > > +           return -EINVAL;
> > > > +
> > > > +   irq_r = regmap_irq_get_virq(irq_data, MAX77650_INT_nEN_R);
> > > > +   if (irq_r <= 0)
> > > > +           return -EINVAL;
> > >
> > > Ugh, it would be better if you handled IRQ mapping in the MFD piece and
> > > passed it as resources of platform device. Then you'd simply call
> > > platform_get_irq() here and did not have to reach into parent device for
> > > "irq_dara".
> >
> > These device IRQs were defined and registered with the Regmap *set*
> > (actually init()) APIs and thus should be pulled out using the
> > appropriate reverse Regmap *get* APIs here in the device.
> >
> > Registering them with Regmap *and* pulling them back out again in the
> > same (MFD in this case) driver, only to register them as platform data
> > is certainly not how I see the API being designed/used.
> >
> > > > +   struct regmap_irq_chip_data *irq_data;
> > > > +   struct device *dev, *parent;
> >
> > > > +   dev = &pdev->dev;
> > > > +   parent = dev->parent;
> > > > +   i2c = to_i2c_client(parent);
> > > > +   irq_data = i2c_get_clientdata(i2c);
> > > > +
> > > > +   map = dev_get_regmap(parent, NULL);
> > > > +   if (!map)
> > > > +           return -ENODEV;
> >
> > However, this hoop jumping is a bit crazy and for the most part
> > superfluous.  Instead, create a struct of attributes you wish to share
> > with the child devices (containing both regmap (which you should call
> > regmap and not map by the way) and irq_data) and pass it as either
> > platform data (preferred) or as device data.
> >
> > If you choose the latter, you do not need to convert from 'device' to
> > 'i2c' to do the look-up.  Since this function (probe()) is provided
> > with a platform_device, you can just use platform_get_drvdata() to
> > achieve the same as above.
> >
> > If you go the preferred (platform data) route, then you should use
> > dev_get_platdata() instead.
> 
> By doing what you are suggesting (introducing platform data) you
> introducing strong dependency between MFD and input piece for no
> different reason. With the current implementation the parent can be
> reworked completely without involving onkey driver.
> 
> I find such clean separation desirable. We are trying to move away
> form platform data where it makes sense.

Never mind.  We found a way forward where everyone wins!

Thanks for your time.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2019-02-14  9:42 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 13:42 [PATCH 00/13] mfd: add support for max77650 PMIC Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 01/13] dt-bindings: mfd: add DT bindings for max77650 Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 02/13] dt-bindings: regulator: " Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 03/13] dt-bindings: power: supply: " Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 04/13] dt-bindings: gpio: " Bartosz Golaszewski
2019-01-21 14:04   ` Linus Walleij
2019-01-21 14:04     ` Linus Walleij
2019-01-18 13:42 ` [PATCH 05/13] dt-bindings: leds: " Bartosz Golaszewski
2019-01-20 16:28   ` Jacek Anaszewski
2019-01-18 13:42 ` [PATCH 06/13] dt-bindings: input: " Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 07/13] mfd: max77650: new core mfd driver Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 08/13] regulator: max77650: add regulator support Bartosz Golaszewski
2019-01-18 18:01   ` Mark Brown
2019-01-18 18:13     ` Bartosz Golaszewski
2019-01-18 18:36       ` Mark Brown
2019-01-18 18:18     ` Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 09/13] power: supply: max77650: add support for battery charger Bartosz Golaszewski
2019-01-23 18:27   ` Sebastian Reichel
2019-01-18 13:42 ` [PATCH 10/13] gpio: max77650: add GPIO support Bartosz Golaszewski
2019-01-21 14:20   ` Linus Walleij
2019-01-21 14:20     ` Linus Walleij
2019-01-21 17:07     ` Bartosz Golaszewski
2019-01-21 17:07       ` Bartosz Golaszewski
2019-01-24 10:30       ` Linus Walleij
2019-01-24 10:30         ` Linus Walleij
2019-01-29 11:00         ` Bartosz Golaszewski
2019-01-29 11:00           ` Bartosz Golaszewski
2019-01-29 13:22           ` Bartosz Golaszewski
2019-01-29 13:22             ` Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 11/13] leds: max77650: add LEDs support Bartosz Golaszewski
2019-01-20 16:39   ` Jacek Anaszewski
2019-01-18 13:42 ` [PATCH 12/13] input: max77650: add onkey support Bartosz Golaszewski
2019-01-19  9:03   ` Dmitry Torokhov
2019-01-21 10:52     ` Bartosz Golaszewski
2019-01-28 19:22       ` Dmitry Torokhov
2019-02-12 20:34     ` Lee Jones
2019-02-13  7:30       ` Dmitry Torokhov
2019-02-14  9:42         ` Lee Jones [this message]
2019-01-18 13:42 ` [PATCH 13/13] MAINTAINERS: add an entry for max77650 mfd driver Bartosz Golaszewski

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=20190214094248.GI13737@dell \
    --to=lee.jones@linaro.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=brgl@bgdev.pl \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.