Dear Takashi-san, Am 19.10.2015 um 07:23 schrieb Takashi Iwai:
On Mon, 19 Oct 2015 00:47:36 +0200, Andreas F4rber wrote:
Am 17.10.2015 um 09:11 schrieb Takashi Iwai:
On Sat, 17 Oct 2015 01:30:08 +0200, Andreas F4rber wrote:
FW_LOADER_USER_HELPER_FALLBACK was set in vanilla but not in default, so I enabled it in default, too.
No, it should be disabled. It's enabled in vanilla because we had a backport fix patch before it landed to stable kernel. So vanilla kernel had to choose this while others could deselect it. Now it's fixed in upstream, so we should correct vanilla, too...
That's what happens when deviations are not explained in the commit message... :)
Yeah, the discussion is found in the bug mentioned in the commit (boo#944661).
We must be talking about different commits! This patch by Guillaume, which was for stable branch only (v4.2.3), did not mention any boo# in but had the following hunks in v2: --- a/config/armv6hl/default +++ b/config/armv6hl/default @@ -1508,6 +1526,7 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE="" +CONFIG_FW_LOADER_USER_HELPER=y # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set CONFIG_WANT_DEV_COREDUMP=y CONFIG_ALLOW_DEV_COREDUMP=y vs. --- a/config/armv6hl/vanilla +++ b/config/armv6hl/vanilla @@ -1505,7 +1521,8 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE="" -# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set +CONFIG_FW_LOADER_USER_HELPER=y +CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y CONFIG_WANT_DEV_COREDUMP=y CONFIG_ALLOW_DEV_COREDUMP=y CONFIG_DEV_COREDUMP=y commit 549889bcb42c5185f23935091a29c074e34c89c4 Author: Guillaume GARDET <guillaume.gardet@free.fr> Date: Fri Oct 16 15:23:51 2015 +0200 config: armv6hl: Update and re-enable default and vanilla configs Update and re-enable default and vanilla configs. Signed-off-by: Guillaume GARDET <guillaume.gardet@free.fr> [AF: Made FW_LOADER_USER_HELPER_FALLBACK consistent] Signed-off-by: Andreas Färber <afaerber@suse.de>
I tried disabling the option, but on stable branch for one of them it's not possible yet, a few LED drivers still select it.
If a LED driver selected it, it must be a bug. This was fixed for lp55xx. Which driver still does it...?
stable armv6hl vanilla: Selected by: DRM_STI [=n] && HAS_IOMEM [=y] && DRM [=y] && (\ SOC_STIH415 [=n] || SOC_STIH416 [=n] || ARCH_MULTIPLATFORM [=y]) && \ HAVE_DMA_ATTRS [=y] || LEDS_LP55XX_COMMON [=m] && NEW_LEDS [=y] && (\ LEDS_LP5521 [=m] || LEDS_LP5523 [=m] || LEDS_LP5562 [=m] || \ LEDS_LP8501 [=m]) STi is armv7hl only, so not enabled here. It seems that the fix you are talking about is not yet in 4.2.3 / stable then.
Some months ago we had an issue with firmware loading on Chromebooks that was mysteriously worked around by enabling that option, so I assume it does no harm leaving it enabled until this is sorted out.
No, this option is known to be really harmful, already caused too many problems, so it must be disabled again.
I'm going to fix to disable this all on master now, at least.
Please do then. But whatever is or is not on master really has nothing to do with this patch here. ;) Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org