From: robert.jarzmik@free.fr (Robert Jarzmik)
To: linux-arm-kernel@lists.infradead.org
Subject: gpio-pxa initcall level change and machine init breakage
Date: Thu, 25 Apr 2013 21:36:22 +0200 [thread overview]
Message-ID: <87ppxiz9l5.fsf@free.fr> (raw)
In-Reply-To: CACRpkdYLCKKZZFi6Y-viPUvrwupJGzfxr3f20a1emp-9qE0YBg@mail.gmail.com
Linus Walleij <linus.walleij@linaro.org> writes:
> On Tue, Apr 23, 2013 at 9:42 PM, Mike Dunn <mikedunn@newsguy.com> wrote:
>
>> On a more general note... I'm surprised that gpiolib can not run earlier, for
>> something so low-level.
>
> Well I think the patch we're discussing is making it run less early, and it
> can actually run as arch_initcall() or similar if you wish (it's up to the
> driver).
>
> However that is beside the point, Haojian is still doing the right thing
> trying to push this to driver init (==module_init) level. The reason is
> that basically all hardware drivers should be initialized at this level
> because the other init levels are basically for other things and driver
> deps are just shoehorned into them.
>
> Instead of relying on things to be set up early one shall rely on
> deferred probe.
Hi Linus,
Even if that is the long term goal, and I agree with that goal, let me quote
Documentation/gpio.txt : "However, for spinlock-safe GPIOs it's OK to use them
before tasking is enabled, as part of early board setup.".
When gpio abstraction was written, it was assumed GPIO usage was usable in early
platform setup code. As this was granted, we (board maintainers) coded
accordingly.
Now this patch breaks boards. I disagree in having my board code broken without
notice. What I would find less intrusive would be to :
(a) revert the patch
(b) inform board maintainers that they must fix their board code (for example
give them 1 window)
(c) put back the patch. Board maintainers who did not amend their board
code cannot say anymore they didn't know it. Board maintainers will also have
time to rise objections if they think they cannot change their board code
(which I do not believe is possible, but who knows ...)
Ah and change the Documentation too I think, if you want GPIO to be only usable
from device initcall level.
> Alas, it is not an easy change, and not expected to happen quickly
> or painlessly.
Sure, so let's do it in right order, shall we ?
Cheers.
--
Robert
PS: When I say "broken code", in the mioa701 case, my phone doesn't wakeup on
phone calls. Disturbing, isn't it ?
next prev parent reply other threads:[~2013-04-25 19:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-20 15:26 gpio-pxa initcall level change and machine init breakage Mike Dunn
2013-04-21 6:02 ` Haojian Zhuang
2013-04-21 22:23 ` Mike Dunn
2013-04-22 0:58 ` Haojian Zhuang
2013-04-23 7:26 ` Linus Walleij
2013-04-23 7:49 ` Haojian Zhuang
2013-04-23 19:42 ` Mike Dunn
2013-04-24 19:37 ` Linus Walleij
2013-04-25 19:36 ` Robert Jarzmik [this message]
2013-04-25 21:22 ` Linus Walleij
2013-04-26 17:48 ` Robert Jarzmik
2013-04-26 12:38 ` Mike Dunn
2013-04-24 16:07 ` Mike Dunn
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=87ppxiz9l5.fsf@free.fr \
--to=robert.jarzmik@free.fr \
--cc=linux-arm-kernel@lists.infradead.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.