linux-kernel - Re: [PATCH] ASoC: rt5640: Omit ACPI match table only if !ACPI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 Sep 2013 13:21:04 +0200
From:	Thierry Reding <thierry.reding@...il.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Liam Girdwood <lgirdwood@...il.com>, alsa-devel@...a-project.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ASoC: rt5640: Omit ACPI match table only if !ACPI

On Thu, Sep 19, 2013 at 11:45:25AM +0100, Mark Brown wrote:
> On Thu, Sep 19, 2013 at 11:18:06AM +0200, Thierry Reding wrote:
> > The ACPI_PTR() macro evaluates to NULL if ACPI is disabled and hence the
> > ACPI match table won't be used, causing the compiler to complain. Avoid
> > this by protecting the table using an #ifdef CONFIG_ACPI.
> 
> Applied, thanks.  Like I was saying to Olof we really should be able to
> do better than needing the ifdefs though.

The struct device_driver's .acpi_match_table field is unconditionally
declared and the ACPI table with one entry and the sentinel weighs in
at 26 bytes, so perhaps doing away with the conditionals would be an
equally good option.

Or perhaps we can annotate the table so that the compiler will stop
complaining but remove the table nonetheless if it isn't used. Similarly
to what we can do with

	if (IS_ENABLED(CONFIG_FOO)) {
		...
	}

constructs. I can't really think of a way to do that, though. Perhaps
gcc will throw away the table anyway, so we'll just need a way to make
it shut up?

Thierry

Content of type "application/pgp-signature" skipped