From: Mark Brown <broonie@kernel.org>
To: "Andrew F. Davis" <afd@ti.com>
Cc: Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Lee Jones <lee.jones@linaro.org>,
Alexandre Courbot <gnurou@gmail.com>,
Grygorii Strashko <grygorii.strashko@ti.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
Date: Tue, 10 Nov 2015 09:57:19 +0000 [thread overview]
Message-ID: <20151110095719.GC12392@sirena.org.uk> (raw)
In-Reply-To: <5640DAC0.9080008@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3134 bytes --]
On Mon, Nov 09, 2015 at 11:41:20AM -0600, Andrew F. Davis wrote:
> On 11/06/2015 03:16 PM, Mark Brown wrote:
> >There are cases where it's useful where we're abstracting something and
> >gaining some meaningful reuse. This really does not appear to be one of
> >those cases, there are no parameters in the DT and the compatible string
> >is the full device name.
> As before I see no reason to make that call now and limit ourselves.
To repeat *yet* *again* the point is that putting the current Linux
driver model into the DT is limiting our future selves.
> >You do not need to populate it. There is no value in populating it and
> >as previously discussed putting the Linux driver model into DT can be
> >actively harmful if we change our idea of how we should model things.
> The dev passed to regulator_register needs to have of_node populated for
> your OF init_data helper to work. Devices with OF tables can just pass
> their own dev. Others have to use their parents' nodes, this is a
> workaround, OF devices should be probed with their of_node pre-populated.
This is not a workaroud, the only reason you think it is a workaround is
the desire to directly represent the Linux device model in the DT.
> >>>Please stop this. I don't understand why you are pushing so hard to put
> >>>the Linux device model representation of the device into DT but it's
> >>>getting very repetitive.
> >>I'm not pushing anything, this is how other sub-nodes of MFD devices are
> >Every time we go through this we finish the discussion and then you come
> >back with yet another excuse for trying to push the current Linux device
> >model into the DT or another version of the patch with the same problem.
> I keep finding different problems, do you expect me to ignore them?
You are making minor restatements of the same thing over and over again
which ignore the main feedback.
> >The fact that other people have merged imperfect code into the kernel is
> >not a good reason to merge even more of it when we have better tools.
> >Looking at that binding I'm seeing no reason why any of the subfunctions
> >should have compatible strings (and if we're going down the route you're
> >trying to go down we really ought to have something in the binding for
> >at least an interrupt controller in there as well...).
> These are not "subfunctions" they are full drivers, they only need
> register accessors passed in, they do not call the core and the core
> does not call them.
To repeat *yet* *again* they are groupings of functionality which happen
to represent the way Linux models devices right now. There's no
generality in there, it's just a dump of the current Linux model of the
functions into the DT.
> If your problem is with the DT binding for this or other MFDs, then
> nack *them* and explain to everyone why what they are doing is wrong
> and why regulators should be special cases. Blocking the regulator
> drivers to force a change in DT is not going to fix this issue.
Of course this is a negative review of the binding! What on earth did
you think my feedback meant? The driver and the binding go together.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-11-10 9:58 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-01 20:37 [PATCH v4 0/5] mfd: tps65912: Driver rewrite with DT support Andrew F. Davis
2015-10-01 20:37 ` [PATCH v4 1/5] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC Andrew F. Davis
2015-10-01 20:37 ` [PATCH v4 2/5] mfd: tps65912: Remove old driver in preparation for new driver Andrew F. Davis
2015-10-05 9:28 ` Lee Jones
2015-10-05 9:29 ` Lee Jones
2015-10-05 16:01 ` Andrew F. Davis
2015-10-01 20:37 ` [PATCH v4 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC Andrew F. Davis
2015-10-01 20:51 ` kbuild test robot
[not found] ` <20151002095859.GN12635@sirena.org.uk>
2015-10-02 13:32 ` [lkp] " Fengguang Wu
2015-10-02 13:47 ` Mark Brown
2015-10-01 20:57 ` kbuild test robot
2015-10-01 20:57 ` kbuild test robot
2015-10-01 23:49 ` Andrew F. Davis
2015-10-05 9:24 ` Lee Jones
2015-10-05 9:27 ` Lee Jones
2015-10-12 15:06 ` Andrew F. Davis
2015-10-13 7:34 ` Lee Jones
2015-10-01 20:37 ` [PATCH v4 4/5] regulator: tps65912: Add regulator " Andrew F. Davis
2015-10-02 19:21 ` Grygorii Strashko
2015-10-22 16:47 ` Mark Brown
2015-10-23 12:46 ` Andrew F. Davis
2015-10-23 23:18 ` Mark Brown
2015-10-24 0:11 ` Andrew F. Davis
2015-10-24 22:14 ` Mark Brown
2015-10-25 20:45 ` Andrew F. Davis
2015-10-26 0:43 ` Mark Brown
2015-10-26 15:47 ` Andrew F. Davis
2015-10-27 0:16 ` Mark Brown
2015-10-27 14:23 ` Andrew F. Davis
2015-11-04 15:35 ` Andrew F. Davis
2015-11-05 10:14 ` Mark Brown
2015-11-05 18:04 ` Andrew F. Davis
2015-11-06 10:43 ` Mark Brown
2015-11-06 18:10 ` Andrew F. Davis
2015-11-06 21:16 ` Mark Brown
2015-11-09 17:41 ` Andrew F. Davis
2015-11-10 9:57 ` Mark Brown [this message]
2015-11-10 16:47 ` Andrew F. Davis
2015-11-10 17:04 ` Mark Brown
2015-11-10 17:52 ` Andrew F. Davis
2015-11-10 18:44 ` Mark Brown
2015-11-10 19:40 ` Andrew F. Davis
2015-11-16 18:23 ` Mark Brown
2015-10-01 20:37 ` [PATCH v4 5/5] gpio: tps65912: Add GPIO " Andrew F. Davis
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=20151110095719.GC12392@sirena.org.uk \
--to=broonie@kernel.org \
--cc=afd@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=gnurou@gmail.com \
--cc=grygorii.strashko@ti.com \
--cc=ijc+devicetree@hellion.org.uk \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@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).