From: Mark Brown <broonie@kernel.org>
To: Daniel Kurtz <djkurtz@chromium.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Grant Likely <grant.likely@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Yingjoe Chen <yingjoe.chen@mediatek.com>,
Hongzhou Yang <hongzhou.yang@mediatek.com>,
Fabio Estevam <fabio.estevam@freescale.com>,
Fabian Frederick <fabf@skynet.be>,
Maoguang Meng <maoguang.meng@mediatek.com>,
Axel Lin <axel.lin@ingics.com>,
"open list:PIN CONTROL SUBSYSTEM" <linux-gpio@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH] pinctrl: mediatek: convert to arch_initcall
Date: Thu, 31 Dec 2015 22:07:12 +0000 [thread overview]
Message-ID: <20151231220712.GD16023@sirena.org.uk> (raw)
In-Reply-To: <CAGS+omA9AarzE2sp1Ry3RuOt8EOa-sL=DL1iDA2OeVVdjn=xgg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2392 bytes --]
On Thu, Dec 31, 2015 at 09:45:51PM +0800, Daniel Kurtz wrote:
> On Thu, Dec 31, 2015 at 1:22 AM, Mark Brown <broonie@kernel.org> wrote:
> > I really don't think we should be applying this sort of stuff unless
> > things are actively broken right now. It's a bit of a rabbit hole we
> > could spend a long time going down tweaking things for different
> > systems in the same way that tweaking the link order can be and it masks
> > the underlying issues.
> Things are actively broken right now, in the sense that there are many
> needless probe deferrals on boot.
That's just noisy, everything does end up loading OK. If the noise is a
problem working on fixing the underlying problem with not being able to
figure out dependencies seems like a better thing. When we discussed
this on the kernel summit list it wasn't clear everyone was convinced
this was even a problem (I think it is since it obscures real
information). Actual breakage to me is something that never sorts
itself out.
> These are pinctrl drivers, which are required to load before every
> other driver that requests a gpio.
> AFAICT, the pinctrl is part of the platform "architecture", hence why
> I suggest we move this to arch_initcall().
This is exactly the sort of hacking that leads to problems - you can
also make the same argument for a bunch of other things like regulators
but then you find there's circular dependencies or extra devices with
different requirements on some systems that cause further issues and
need more special casing, or you find that some other device gets pushed
earlier so you have to go round tweaking everything it uses. It's not
that the device is magic, it's that we don't understand how to handle
dependencies well enough. Raphael did say he was going to work on
something for this, I'm not sure where it got to though.
> arch_initcall() is also consistent with 39 other pinctrl drivers in
> drivers/pinctrl.
> 19 others use subsys_initcall(), core_initcall() or
> postcore_initcall(), any of which would also work.
It's fairly clear that there's at least a case for simplifying the
existing practice here, for example by moving everything into a single
(perhaps aliased) initcall rather than by randomly picking a level per
system or by actually fiddling with the link ordering if the case is
sufficiently clear that pinctrl in general ought to load earlier than it
does.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: broonie@kernel.org (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pinctrl: mediatek: convert to arch_initcall
Date: Thu, 31 Dec 2015 22:07:12 +0000 [thread overview]
Message-ID: <20151231220712.GD16023@sirena.org.uk> (raw)
In-Reply-To: <CAGS+omA9AarzE2sp1Ry3RuOt8EOa-sL=DL1iDA2OeVVdjn=xgg@mail.gmail.com>
On Thu, Dec 31, 2015 at 09:45:51PM +0800, Daniel Kurtz wrote:
> On Thu, Dec 31, 2015 at 1:22 AM, Mark Brown <broonie@kernel.org> wrote:
> > I really don't think we should be applying this sort of stuff unless
> > things are actively broken right now. It's a bit of a rabbit hole we
> > could spend a long time going down tweaking things for different
> > systems in the same way that tweaking the link order can be and it masks
> > the underlying issues.
> Things are actively broken right now, in the sense that there are many
> needless probe deferrals on boot.
That's just noisy, everything does end up loading OK. If the noise is a
problem working on fixing the underlying problem with not being able to
figure out dependencies seems like a better thing. When we discussed
this on the kernel summit list it wasn't clear everyone was convinced
this was even a problem (I think it is since it obscures real
information). Actual breakage to me is something that never sorts
itself out.
> These are pinctrl drivers, which are required to load before every
> other driver that requests a gpio.
> AFAICT, the pinctrl is part of the platform "architecture", hence why
> I suggest we move this to arch_initcall().
This is exactly the sort of hacking that leads to problems - you can
also make the same argument for a bunch of other things like regulators
but then you find there's circular dependencies or extra devices with
different requirements on some systems that cause further issues and
need more special casing, or you find that some other device gets pushed
earlier so you have to go round tweaking everything it uses. It's not
that the device is magic, it's that we don't understand how to handle
dependencies well enough. Raphael did say he was going to work on
something for this, I'm not sure where it got to though.
> arch_initcall() is also consistent with 39 other pinctrl drivers in
> drivers/pinctrl.
> 19 others use subsys_initcall(), core_initcall() or
> postcore_initcall(), any of which would also work.
It's fairly clear that there's at least a case for simplifying the
existing practice here, for example by moving everything into a single
(perhaps aliased) initcall rather than by randomly picking a level per
system or by actually fiddling with the link ordering if the case is
sufficiently clear that pinctrl in general ought to load earlier than it
does.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151231/a0030c2e/attachment.sig>
next prev parent reply other threads:[~2015-12-31 22:07 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-22 13:46 [PATCH] pinctrl: mediatek: convert to arch_initcall Daniel Kurtz
2015-12-22 13:46 ` Daniel Kurtz
2015-12-22 13:46 ` Daniel Kurtz
2015-12-22 15:11 ` Linus Walleij
2015-12-22 15:11 ` Linus Walleij
2015-12-30 17:22 ` Mark Brown
2015-12-30 17:22 ` Mark Brown
2015-12-31 13:45 ` Daniel Kurtz
2015-12-31 13:45 ` Daniel Kurtz
2015-12-31 22:07 ` Mark Brown [this message]
2015-12-31 22:07 ` Mark Brown
[not found] ` <20151231220712.GD16023-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-01-01 1:56 ` Daniel Kurtz
2016-01-01 1:56 ` Daniel Kurtz
2016-01-01 1:56 ` Daniel Kurtz
2016-01-01 14:27 ` Matthias Brugger
2016-01-01 14:27 ` Matthias Brugger
2016-01-01 17:29 ` Linus Walleij
2016-01-01 17:29 ` Linus Walleij
2016-01-04 17:12 ` Mark Brown
2016-01-04 17:12 ` Mark Brown
2016-01-04 18:23 ` Mark Brown
2016-01-04 18:23 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2015-12-18 4:21 Daniel Kurtz
2015-12-18 4:21 ` Daniel Kurtz
2015-12-18 4:21 ` Daniel Kurtz
2015-12-18 15:06 ` Yingjoe Chen
2015-12-18 15:06 ` Yingjoe Chen
2015-12-21 6:51 ` Daniel Kurtz
2015-12-21 6:51 ` Daniel Kurtz
2015-12-21 6:51 ` Daniel Kurtz
2015-12-21 12:39 ` Yingjoe Chen
2015-12-21 12:39 ` Yingjoe Chen
2015-12-21 12:45 ` Daniel Kurtz
2015-12-21 12:45 ` Daniel Kurtz
2015-12-22 10:23 ` Linus Walleij
2015-12-22 10:23 ` Linus Walleij
[not found] ` <CACRpkdbuL5Kjeqb-zJg9DmoxKzy7vphYgBTG-Ffh2i=UVH97ug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-22 13:36 ` Yingjoe Chen
2015-12-22 13:36 ` Yingjoe Chen
2015-12-22 13:36 ` Yingjoe Chen
2015-12-22 13:41 ` Daniel Kurtz
2015-12-22 13:41 ` Daniel Kurtz
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=20151231220712.GD16023@sirena.org.uk \
--to=broonie@kernel.org \
--cc=axel.lin@ingics.com \
--cc=djkurtz@chromium.org \
--cc=fabf@skynet.be \
--cc=fabio.estevam@freescale.com \
--cc=grant.likely@linaro.org \
--cc=hongzhou.yang@mediatek.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=maoguang.meng@mediatek.com \
--cc=matthias.bgg@gmail.com \
--cc=yingjoe.chen@mediatek.com \
/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.