linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Anton Vorontsov <cbouatmailru@gmail.com>
To: Bill Gatliff <bgat@billgatliff.com>
Cc: Linux/PPC Development <linuxppc-dev@ozlabs.org>
Subject: Re: Requesting a GPIO that hasn't been registered yet
Date: Wed, 31 Mar 2010 12:32:18 +0400	[thread overview]
Message-ID: <20100331083218.GA15664@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <4BB2BBDD.6050304@billgatliff.com>

On Tue, Mar 30, 2010 at 10:05:01PM -0500, Bill Gatliff wrote:
[...]
> In other words, the GPIO pin I'm using for the key is one of the bits on
> my pca953x GPIO expander chip.
> 
> The above would all be great, except that I haven't come up with a way
> to make sure that my encoder_button doesn't try to probe before lext60
> is available.  In fact, I'm consistently getting initialization in the
> wrong order!
> 
> Eventually the GPIO expander chip gets plugged in, because I can see it
> show up in sysfs.  And what's really odd is, I recently made similar
> mods to gpio_leds and they are working fine--- although the GPIO pin is
> on a pca953x at address 20, instead of 60.  I'm at a loss to explain why
> one works, but the other doesn't.  And I don't know how to really fix
> this problem for good!

That's because of drivers/Makefile:

obj-$(CONFIG_INPUT)             += input/
...
obj-y                           += i2c/ media/
...
obj-$(CONFIG_NEW_LEDS)          += leds/

So, all these drivers use module_init(), which means that the
order of execution depends on link order. To fix probing you need
to move i2c/ above input/:

diff --git a/drivers/Makefile b/drivers/Makefile
index 34f1e10..d31bb52 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -67,12 +67,12 @@ obj-$(CONFIG_USB)		+= usb/
 obj-$(CONFIG_USB_MUSB_HDRC)	+= usb/musb/
 obj-$(CONFIG_PCI)		+= usb/
 obj-$(CONFIG_USB_GADGET)	+= usb/gadget/
+obj-y				+= i2c/ media/
 obj-$(CONFIG_SERIO)		+= input/serio/
 obj-$(CONFIG_GAMEPORT)		+= input/gameport/
 obj-$(CONFIG_INPUT)		+= input/
 obj-$(CONFIG_I2O)		+= message/
 obj-$(CONFIG_RTC_LIB)		+= rtc/
-obj-y				+= i2c/ media/
 obj-$(CONFIG_PPS)		+= pps/
 obj-$(CONFIG_W1)		+= w1/
 obj-$(CONFIG_POWER_SUPPLY)	+= power/

      reply	other threads:[~2010-03-31  8:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-31  3:05 Requesting a GPIO that hasn't been registered yet Bill Gatliff
2010-03-31  8:32 ` Anton Vorontsov [this message]

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=20100331083218.GA15664@oksana.dev.rtsoft.ru \
    --to=cbouatmailru@gmail.com \
    --cc=bgat@billgatliff.com \
    --cc=linuxppc-dev@ozlabs.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).