From: Baruch Siach <baruch@tkos.co.il>
To: David Cohen <david.a.cohen@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
linux-gpio@vger.kernel.org, linux-xtensa@linux-xtensa.org
Subject: Re: [PATCH v3] gpio: driver for Xtensa GPIO32
Date: Mon, 16 Dec 2013 07:50:32 +0200 [thread overview]
Message-ID: <20131216055032.GB3807@tarshish> (raw)
In-Reply-To: <20131212192300.GB14726@psi-dev26.jf.intel.com>
Hi David,
On Thu, Dec 12, 2013 at 11:23:00AM -0800, David Cohen wrote:
> On Thu, Dec 12, 2013 at 08:24:42PM +0200, Baruch Siach wrote:
> > On Thu, Dec 12, 2013 at 10:15:58AM -0800, David Cohen wrote:
> > > On Thu, Dec 12, 2013 at 11:18:41AM +0200, Baruch Siach wrote:
> > > > +static int __init xtensa_gpio_init(void)
> > > > +{
> > > > + struct platform_device *pdev;
> > > > +
> > > > + pdev = platform_device_register_simple("xtensa-gpio", 0, NULL, 0);
> > >
> > > Is it what you really want to do? It means this driver will probe
> > > regardless it really should or not.
> >
> > If you have XCHAL_CP_ID_XTIOP defined in your xtensa variant tie.h header,
> > then this device is available. Otherwise, this driver doesn't even build. If
> > you don't want the kernel to manage the GPIO32 IO port, then just disable the
> > driver in the kernel configuration.
> >
> > Does this sound reasonable enough?
>
> Then I think it's a bit worse :)
> You can't make kernel compilation to fail when this GPIO driver is not
> meant to be probed.
> I'm not familiar with xtensa, so can't be strongly against platform
> device registration inside the driver's init function. But you need to
> fix your Kconfig to not make this driver available when it's not
> compilable.
I understand your concern, as currently randconfig enabling this driver will
break the build. I'm not sure what is the right solution though. We could
depend on, say HAVE_XTENSA_GPIO32, and select it from arch/xtensa/Kconfig for
the appropriate xtensa variants. The problem is that no current mainline
xtensa variant supports GPIO32. So, at some future point one of those who are
looking for unreferenced Kconfig symbols will just remove the whole driver.
Suggestions for a better solution are welcome.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
next prev parent reply other threads:[~2013-12-16 5:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-12 9:18 [PATCH v3] gpio: driver for Xtensa GPIO32 Baruch Siach
2013-12-12 13:35 ` Linus Walleij
2013-12-12 18:15 ` David Cohen
2013-12-12 18:24 ` Baruch Siach
2013-12-12 19:23 ` David Cohen
2013-12-16 5:50 ` Baruch Siach [this message]
2013-12-16 6:11 ` [Linux-Xtensa] " Marc Gauthier
2013-12-16 6:40 ` Baruch Siach
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=20131216055032.GB3807@tarshish \
--to=baruch@tkos.co.il \
--cc=david.a.cohen@linux.intel.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-xtensa@linux-xtensa.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.