linux-kernel - Re: [PATCH 3.1-rc3] gpio/omap: fix build error with certain OMAP1 configs

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:	Tue, 11 Oct 2011 00:12:45 +0300 (EEST)
From:	Aaro Koskinen <aaro.koskinen@....fi>
To:	Janusz Krzysztofik <jkrzyszt@....icnet.pl>
cc:	Kevin Hilman <khilman@...com>,
	Grant Likely <grant.likely@...retlab.ca>,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
	tony@...mide.com
Subject: Re: [PATCH 3.1-rc3] gpio/omap: fix build error with certain OMAP1
 configs

Hi,

On Fri, 7 Oct 2011, Janusz Krzysztofik wrote:
> Dnia wtorek, 23 sierpnia 2011 o 19:11:47 Kevin Hilman napisał(a):
>> Janusz Krzysztofik <jkrzyszt@....icnet.pl> writes:
>>> With commit f64ad1a0e21a, "gpio/omap: cleanup _set_gpio_wakeup(), remove
>>> ifdefs", access to build time conditionally omitted 'suspend_wakeup'
>>> member of the 'gpio_bank' structure has been placed unconditionally in
>>> function _set_gpio_wakeup(), which is always built. This resulted in the
>>> driver compilation broken for certain OMAP1, i.e., non-OMAP16xx,
>>> configurations.
>>>
>>> Really required or not in previously excluded cases, define this
>>> structure member unconditionally as a fix.
>>>
>>> Tested with a custom OMAP1510 only configuration.
>>>
>>> Signed-off-by: Janusz Krzysztofik <jkrzyszt@....icnet.pl>
>>
>> Verified that this fixes a build problem when building for OMAP1
>> (730/850 only)
>>
>> Acked-by: Kevin Hilman <khilman@...com>

Tested-by: Aaro Koskinen <aaro.koskinen@....fi>

>> Grant, can you queue this as a fix for 3.1-rc?
>
> Sorry for being so late with checking this, but it looks like this patch
> never got into 3.1-rc, as it should, leaving the issue not fixed.
> Any chance for it still being pushed into 3.1?

This patch is one-liner, and still needed to get 3.1-rc9 compiled and
running on e.g. Amstrad E3, so I think it should get into 3.1.

A.