All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
To: Sebastian Reichel <sre@kernel.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	mazziesaccount@gmail.com, lee.jones@linaro.org,
	robh+dt@kernel.org, mark.rutland@arm.com, lgirdwood@gmail.com,
	broonie@kernel.org, gregkh@linuxfoundation.org,
	rafael@kernel.org, mturquette@baylibre.com, sboyd@kernel.org,
	linus.walleij@linaro.org, bgolaszewski@baylibre.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,
	mikko.mutanen@fi.rohmeurope.com,
	heikki.haikola@fi.rohmeurope.com
Subject: Re: [RFC PATCH v1 13/13] watchdog: bd70528: Initial support for ROHM BD70528 watchdog block
Date: Thu, 24 Jan 2019 12:44:35 +0200	[thread overview]
Message-ID: <20190124104434.GF2559@localhost.localdomain> (raw)
In-Reply-To: <20190123174728.uu7zhno5xea2bga7@earth.universe>

On Wed, Jan 23, 2019 at 06:47:28PM +0100, Sebastian Reichel wrote:
> Hi,
> 
> On Tue, Jan 22, 2019 at 08:03:09PM +0200, Matti Vaittinen wrote:
> > On Tue, Jan 22, 2019 at 09:40:56AM -0800, Guenter Roeck wrote:
> > > On Tue, Jan 22, 2019 at 07:10:23PM +0200, Matti Vaittinen wrote:
> > > > On Tue, Jan 22, 2019 at 07:47:50AM -0800, Guenter Roeck wrote:
> > > > > On Tue, Jan 22, 2019 at 11:48:36AM +0200, Matti Vaittinen wrote:
> > > > > > +static int bd70528_wdt_probe(struct platform_device *pdev)
> > > > > > +{
> > > > > > +	struct bd70528 *tmp;
> > > > > > +	struct bd70528 *bd70528;
> > > > > > +	int ret;
> > > > > > +
> > > > > > +	tmp = dev_get_drvdata(pdev->dev.parent);
> > > > > > +	if (!tmp) {
> > > > > > +		dev_err(&pdev->dev, "No MFD driver data\n");
> > > > > > +		return -EINVAL;
> > > > > > +	}
> > > > > > +	bd70528 = devm_kzalloc(&pdev->dev, sizeof(*bd70528), GFP_KERNEL);
> > > > > > +	if (!bd70528)
> > > > > > +		return -ENOMEM;
> > > > > > +
> > > > > > +	*bd70528 = *tmp;
> > > > > > +	bd70528->chip.dev = &pdev->dev;
> > > > > 
> > > > > This is wrong.
> > > > > You should not copy the parent's driver data but have local driver
> > > > > data as needed which then points to the parent's driver data if
> > > > > needed. I assume this is why the mutex is a pointer, but that
> > > > > just shows that the whole approach is wrong.
> > > > 
> > > > Mutex is a pointer because we want to use same mutex from WDT and RTC.
> > > > We can sure point to parent data but then we still need our own dev
> > > > pointer. So we can have a struct with pointer to parent data and dev
> > > > pointer - but I'm not at all sure it is any clearer.
> > > 
> > > As I said, that is wrong. To say it in plaintext, I won't accept
> > > the driver if it copies the parent's driver data. The driver should
> > > have and use its own driver data, and only maintain a pointer to
> > > its parent's driver data. And most definitely you don't want to
> > > copy and use any device data structure from the parent.
> > 
> > Allright. At the moment the WDT driver only needs regmap pointer from
> > parent. I'm not sure if it will later need DT or "chip type" - but I
> > will change this.
> 
> You probably want to use this:
> 
> dev_get_regmap(pdev->dev.parent, NULL);

Thanks a bunch Sebastian. All help is highly appreciated!! =)

Unfortunately I forgot to mention the key thing - the RTC mutex. We also
need that because RTC needs to stop WDT when RTC is adjusted as the WDT
uses RTC as counter - and jumping the RTC WDT enabled might trigger WDT
or have other consequences.

Se even if we used dev_get_regmap (which is slightly heavier than
accessing direct pointer) - we would still need at least the mutex from
parent data, possibly also the chip type and if we want to avoid code
dublication - then also the WDT start/stop function.

Thus I guess we can as well keep the regmap in parent data because we
need the parent data anyways, right?

Br
	Matti Vaittinen

-- 
Matti Vaittinen
ROHM Semiconductors

~~~ "I don't think so," said Rene Descartes.  Just then, he vanished ~~~

  reply	other threads:[~2019-01-24 10:44 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22  9:41 [RFC PATCH v1 00/13] support ROHM BD70528 PMIC Matti Vaittinen
2019-01-22  9:42 ` [RFC PATCH v1 01/13] regmap: regmap-irq: Add main status register support Matti Vaittinen
2019-01-23 15:55   ` Mark Brown
2019-01-22  9:42 ` [RFC PATCH v1 02/13] mfd: bd718x7.h split to ROHM common and bd718x7 specific parts Matti Vaittinen
2019-01-22  9:43 ` [RFC PATCH v1 03/13] regulator: bd718x7 use chip specific and generic data structs Matti Vaittinen
2019-01-23 15:51   ` Mark Brown
2019-01-24  7:16     ` Matti Vaittinen
2019-01-24 10:24       ` Mark Brown
2019-01-22  9:44 ` [RFC PATCH v1 04/13] clk: bd718x7: " Matti Vaittinen
2019-01-22  9:44 ` [RFC PATCH v1 05/13] mfd: bd70528: Support ROHM bd70528 PMIC - core Matti Vaittinen
2019-01-22 14:51   ` Guenter Roeck
2019-01-22 16:20     ` Matti Vaittinen
2019-01-22  9:45 ` [RFC PATCH v1 06/13] clk: bd718x7: Support ROHM BD70528 clk block Matti Vaittinen
2019-01-22  9:45 ` [RFC PATCH v1 07/13] devicetree: bindings: Document first ROHM BD70528 bindings Matti Vaittinen
2019-02-23  0:30   ` Rob Herring
2019-02-28  6:49     ` Matti Vaittinen
2019-02-28 15:37       ` Rob Herring
2019-02-28 15:37         ` Rob Herring
2019-01-22  9:46 ` [RFC PATCH v1 08/13] regulator: bd70528: Support ROHM BD70528 regulator block Matti Vaittinen
2019-01-22  9:46 ` [RFC PATCH v1 09/13] devicetree: bindings: ROHM bd70528 regulator bindings Matti Vaittinen
2019-01-22  9:47 ` [RFC PATCH v1 10/13] gpio: Initial support for ROHM bd70528 GPIO block Matti Vaittinen
2019-01-22  9:47 ` [RFC PATCH v1 11/13] rtc: bd70528: Initial support for ROHM bd70528 RTC Matti Vaittinen
2019-01-22 14:48   ` Guenter Roeck
2019-01-22 16:29     ` Matti Vaittinen
2019-01-22  9:48 ` [RFC PATCH v1 12/13] power: supply: Initial support for ROHM BD70528 PMIC charger block Matti Vaittinen
2019-01-22  9:48 ` [RFC PATCH v1 13/13] watchdog: bd70528: Initial support for ROHM BD70528 watchdog block Matti Vaittinen
2019-01-22 15:47   ` Guenter Roeck
2019-01-22 17:10     ` Matti Vaittinen
2019-01-22 17:40       ` Guenter Roeck
2019-01-22 18:03         ` Matti Vaittinen
2019-01-23 17:47           ` Sebastian Reichel
2019-01-24 10:44             ` Matti Vaittinen [this message]
2019-01-24 14:37               ` Guenter Roeck

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=20190124104434.GF2559@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 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.