search for: config_foo

On 23 August 2016 at 00:42, Martin Peres <martin.peres at free.fr> wrote: > v2: > - guard LED framework calls with ifdef CONFIG_LEDS_CLASS > IIRC kernel has the tendency of using static inlines in the headers when CONFIG_foo is not set. Worth using that and removing the ifdef from the source file ? -Emil

'default n' is the default value for any bool or tristate Kconfig setting so there is no need to write it explicitly. Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO is not set' for visible symbols") the Kconfig behavior is the same regardless of 'default n' being present or not: ... One side effect of (and the main motivation for) this change is making the following two definitions behave exactly the same: config FOO...

On 23/08/16 17:43, Emil Velikov wrote: > On 23 August 2016 at 00:42, Martin Peres <martin.peres at free.fr> wrote: >> v2: >> - guard LED framework calls with ifdef CONFIG_LEDS_CLASS >> > IIRC kernel has the tendency of using static inlines in the headers > when CONFIG_foo is not set. Worth using that and removing the ifdef > from the source file ? Oh, you mean, re-defining the functions I use but make them do nothing. However, I should do it in the source file and not in the header since I do not want to export these symbols outside of the object. Do you have...

Hi, Get these now: this one with non-pae builds: arch/i386/kernel/built-in.o: In function `APIC_init_uniprocessor': (.init.text+0x6357): undefined reference to `setup_boot_clock' this on both pae and non-pae (CONFIG_MAGIC_SYSRQ=y): drivers/built-in.o: In function `xencons_rx': (.text+0x17f09): undefined reference to `sysrq_enabled' cheers, Gerd -- Gerd Hoffmann

Hi, Get these now: this one with non-pae builds: arch/i386/kernel/built-in.o: In function `APIC_init_uniprocessor': (.init.text+0x6357): undefined reference to `setup_boot_clock' this on both pae and non-pae (CONFIG_MAGIC_SYSRQ=y): drivers/built-in.o: In function `xencons_rx': (.text+0x17f09): undefined reference to `sysrq_enabled' cheers, Gerd -- Gerd Hoffmann

...n Fri, 12 Apr 2019, Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com> wrote: > 'default n' is the default value for any bool or tristate Kconfig > setting so there is no need to write it explicitly. > > Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO > is not set' for visible symbols") the Kconfig behavior is the same > regardless of 'default n' being present or not: > > ... > One side effect of (and the main motivation for) this change is making > the following two definitions behave exactly the s...

...------------------------------------------------------------ commit 6aaee4960d8a56aeab9d962ce554dff7f987e1fd Author: Ian Campbell <ian.campbell@citrix.com> Date: Fri Apr 26 11:58:46 2013 +0100 xen: arm: correct platform detection in public header. These headers cannot use the CONFIG_FOO defines provided when building Xen (since they aren''t provided when building tools or by external components) and need to use the compiler provided architecture defines. This manifested itself as a failure to build xenctx.c on ARM64 due to the missing symbols contains...

Hi all, This is version three of the patches I previously posted here: v1: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ v2: https://lore.kernel.org/r/20200630173734.14057-1-will at kernel.org Changes since v2 include: * Actually add the barrier in READ_ONCE() for Alpha! * Implement Alpha's smp_load_acquire() using __READ_ONCE(), rather than the other

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

We received a donation of a Titan which has this useless feature allowing users to control the brightness of the LED behind the logo of NVIDIA. In the true spirit of open source, let's expose that to the users of very expensive cards! This patch hooks up this LED/PWM to the LED subsystem which allows blinking it in sync with cpu/disk/network/whatever activity (heartbeat is quite nice!). Users