Age | Commit message (Collapse) | Author | Files | Lines |
|
The Debian armhf architecture uses the ARM EABI hard-float variant,
whereas armel uses the soft-float variant. Although the kernel
doesn't use FP itself, CONFIG_VFP must be enabled to support
hard-float userland and will probably be disabled when supporting a
soft-float userland. So set the architecture to armhf by default when
CONFIG_AEABI and CONFIG_VFP are both enabled.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Fathi Boudra <fathi.boudra@linaro.org>
Reviewed-by: Riku Voipio <riku.voipio@linaro.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
|
|
Fix a couple spelling mistakes.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Michal Marek <mmarek@suse.cz>
|
|
This effectively reverts 932058a5d5f9 ("coccinelle: misc: semantic patch
to delete overly complex return code processing").
There can be both symmetry and readability reasons for not wanting to do
the final function call as part of the return statement and to maintain
a clear separation of success and error paths.
Since this is in no way mandated by the coding standard, let's just
remove this semantic patch to avoid having "clean up" patches being
posted over and over in response to these Coccinelle warnings.
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Michal Marek <mmarek@suse.cz>
|
|
kbuild/gcc uses -include option to include files and -I to provide paths
for #include <> directive. In case of spatch latter option should be
prefixed with two -.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Michal Marek <mmarek@suse.cz>
|
|
The original version only considered the case where the then branch
contains only one call to PTR_ERR. Reimplement the whole thing to allow
multiple calls, with potentially different arguments.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Michal Marek <mmarek@suse.cz>
|