All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olof Johansson <olof@lixom.net>
To: Mark Brown <broonie@kernel.org>
Cc: liam.r.girdwood@linux.intel.com,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH] ASoC: rt5640: ifdef for ACPI module table
Date: Wed, 18 Sep 2013 10:36:20 -0700	[thread overview]
Message-ID: <20130918173620.GA28143@quad.lixom.net> (raw)
In-Reply-To: <20130918172858.GE21013@sirena.org.uk>

On Wed, Sep 18, 2013 at 06:28:58PM +0100, Mark Brown wrote:
> > The problem doesn't show up when you build the driver as a module, because by
> > then the MODULE_DEVICE_TABLE() reference means the table is referenced. But
> > when you don't build as a module, MODULE_GENERIC_TABLE() reduces down to
> > nothing, thus causing this.
> 
> I'd have expected the folks doing the allyesconfig builds to have
> complained then...

Allyes will probably turn on CONFIG_ACPI and thus reference the variable
in the struct device.

> > Only way to avoid is as I see it is to mark the table __maybe_unused,
> > which in this case doesn't look like much of a better option.
> 
> > Most other drivers, for example those using pci or of module tables, have
> > Kconfig dependencies such that there's no need to ifdef. There are plenty of
> > examples of drivers ifdeffing on CONFIG_OF for those tables though.
> 
> Yes, you used to have to ifdef everything but there was a thing about
> stopping bothering doing that.  The same issue applies to the PM
> functions.  It's certainly annoying to have to faff around with the
> ifdefs all the time.
> 
> ISTR Arnd was telling me about this stuff, CCing him.

The PM case is particularly annoying because the device struct members
aren't there when PM is off, so you need the ifdef in the struct device
definition.

With the new of_match_ptr() and ACPI_PTR() you get rid of the
ifdef in struct device for those, but you still want it around
MODULE_DEVICE_TABLE() and the actual definition of the match table.


-Olof

  reply	other threads:[~2013-09-18 17:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-18  6:10 [PATCH] ASoC: rt5640: ifdef for ACPI module table Olof Johansson
2013-09-18  7:26 ` Jarkko Nikula
2013-09-18 15:10   ` Olof Johansson
2013-09-18  9:41 ` Mark Brown
2013-09-18 15:13   ` Olof Johansson
2013-09-18 15:38     ` Mark Brown
2013-09-18 16:53       ` Olof Johansson
2013-09-18 17:28         ` Mark Brown
2013-09-18 17:36           ` Olof Johansson [this message]
2013-09-18 18:34             ` Mark Brown
2013-09-18 18:44               ` Olof Johansson
2013-09-19 12:02                 ` Mark Brown

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=20130918173620.GA28143@quad.lixom.net \
    --to=olof@lixom.net \
    --cc=alsa-devel@alsa-project.org \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=liam.r.girdwood@linux.intel.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.