From: Greg Ungerer <gerg@uclinux.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org, lkml@vger.kernel.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>
Subject: Re: [PATCH] gpio: add a userspace chardev ABI for GPIOs
Date: Wed, 30 Mar 2016 11:49:23 +1000 [thread overview]
Message-ID: <56FB30A3.40405@uclinux.org> (raw)
Hi Linus,
Commit 3c702e99 ("gpio: add a userspace chardev ABI for GPIOs")
breaks booting on all my m68k/ColdFire platforms (with MMU and
without). They all hang during the boot up, the last console
trace is:
...
NR_IRQS:256
\x01 clocksource: pit: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1467848399018 ns
\x01 Calibrating delay loop... 1042.02 BogoMIPS (lpj=5210112)
\x01 pid_max: default: 32768 minimum: 301
\x01 Mount-cache hash table entries: 2048 (order: 0, 8192 bytes)
\x01 Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes)
I traced this back to gpiochip_add_data() when it does the
device_add() call. On my platforms this is being called
before gpiolib_dev_init(), and this seems to be the issue.
So gpio_bus_type has not been registered as a bus yet.
The lowest level ColdFire gpio code (arch/m68k/coldfire/gpio.c)
calls its setup from core_initcall() - and this will call
gpiochip_add_data(). This is being called first, before
the core_initcall() for gpiolib_dev_init().
I can fix by changing the core_initcall() in coldfire/gpio.c
to something like postcore_initcall() and that fixes the boot
problem.
What do you think?
Would you expect that all callers of gpiochip_add_data()
should be after core_initcall()?
Regards
Greg
next reply other threads:[~2016-03-30 1:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-30 1:49 Greg Ungerer [this message]
2016-03-31 5:59 ` [PATCH] gpio: add a userspace chardev ABI for GPIOs Alexandre Courbot
2016-03-31 5:59 ` Alexandre Courbot
2016-03-31 6:43 ` Greg Ungerer
2016-03-31 6:43 ` Greg Ungerer
2016-03-31 12:44 ` Guenter Roeck
2016-03-31 12:44 ` 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=56FB30A3.40405@uclinux.org \
--to=gerg@uclinux.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=lkml@vger.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.