Change the subsystem prefix to: [PATCH] Staging: board: ...
On Tue, Mar 05, 2019 at 11:39:30PM +, Arnold J Chand wrote:
> Fix implicit-function-declaration error by 'extern'-ing the function in
> the file
>
> Signed-off-by: Arnold Chand
> ---
> drivers/staging/board/board.c | 2 ++
> 1 file
On 10/22/2017 06:23 AM, Sean Wang wrote:
On Sat, 2017-10-21 at 10:25 +0200, Matthias Brugger wrote:
When adding the MT6380 compatible, the sentinel for of_device_id was
deleted, which leades to the following compiler error:
FATAL: drivers/soc/mediatek/mtk-pmic-wrap: struct of_device_id is not
On Sat, 2017-10-21 at 10:25 +0200, Matthias Brugger wrote:
> When adding the MT6380 compatible, the sentinel for of_device_id was
> deleted, which leades to the following compiler error:
> FATAL: drivers/soc/mediatek/mtk-pmic-wrap: struct of_device_id is not
> terminated with
When adding the MT6380 compatible, the sentinel for of_device_id was
deleted, which leades to the following compiler error:
FATAL: drivers/soc/mediatek/mtk-pmic-wrap: struct of_device_id is not
terminated with a NULL entry!
Fix this by adding the sentinel again.
Signed-off-by: Matthias Brugger
4.13-stable review patch. If anyone has any objections, please let me know.
--
From: Matt Redfearn
commit 94c3390ab84a6b449accc7351ffda4a0c17bdb92 upstream.
Compiling ebpf_jit.c with gcc 4.9 results in a (likely spurious)
compiler warning, as gcc has detected that the variable
.config to linux build tree
make.cross ARCH=cris
All errors (new ones prefixed by >>):
(post_inc:SI (reg:SI 15 acr))
lib/lz4/lz4_decompress.c: In function 'LZ4_decompress_safe_usingDict':
>> lib/lz4/lz4_decompress.c:487:1: internal compiler error: output_operand:
&
Compiling ebpf_jit.c with gcc 4.9 results in a (likely spurious)
compiler warning, as gcc has detected that the variable "target" may be
used uninitialised. Since -Werror is active, this is treated as an error
and causes a kernel build failure whenever CONFIG_MIPS_EBPF_JIT is
enabled.
arch/mips/ne
.
> >>
> >> drivers/staging/rtl8723bs/core/rtw_ap.c: In function ‘expire_timeout_chk’:
> >> drivers/staging/rtl8723bs/core/rtw_ap.c:442:1: internal compiler error:
> >> in change_address_1, at emit-rtl.c:2126
> >>
> >> drivers/staging/rtl8188e
ut_chk’:
>> drivers/staging/rtl8723bs/core/rtw_ap.c:442:1: internal compiler error:
>> in change_address_1, at emit-rtl.c:2126
>>
>> drivers/staging/rtl8188eu/core/rtw_ap.c: In function ‘expire_timeout_chk’:
>> drivers/staging/rtl8188eu/core/rtw_ap.c:445:1: in
On Sun, Sep 10, 2017 at 11:31 AM, Guenter Roeck wrote:
> xtensa:allmodconfig fails to build in mainline with compiler errors
> as follows.
>
> drivers/staging/rtl8723bs/core/rtw_ap.c: In function ‘expire_timeout_chk’:
> drivers/staging/rtl8723bs/core/rtw_ap.c:442:1: internal
_ap.c:442:1: internal compiler error:
> in change_address_1, at emit-rtl.c:2126
>
> drivers/staging/rtl8188eu/core/rtw_ap.c: In function ‘expire_timeout_chk’:
> drivers/staging/rtl8188eu/core/rtw_ap.c:445:1: internal compiler error:
> in change_address_1, at emit-rtl.c:215
Hi,
xtensa:allmodconfig fails to build in mainline with compiler errors
as follows.
drivers/staging/rtl8723bs/core/rtw_ap.c: In function ‘expire_timeout_chk’:
drivers/staging/rtl8723bs/core/rtw_ap.c:442:1: internal compiler error:
in change_address_1, at emit-rtl.c:2126
drivers/staging
build tree
make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
drivers/staging/rtl8188eu/core/rtw_ap.c: In function 'expire_timeout_chk':
>> drivers/staging/rtl8188eu/core/rtw_ap.c:445:1: internal compiler error: in
>> change_address_1, at e
Hi Daniel,
>>>
>>> So the only arch that sets __ARCH_WANT_SYSCALL_DEPRECATED
>>> is score:
>>>
>>>$ git grep -n __ARCH_WANT_SYSCALL_DEPRECATED
>>>arch/score/include/uapi/asm/unistd.h:7:#define
>>> __ARCH_WANT_SYSCALL_DEPRECATED
>>>include/uapi/asm-generic/unistd.h:837:#ifdef
>>> __ARC
On 08/04/2017 08:33 PM, Joel Fernandes wrote:
On Fri, Aug 4, 2017 at 6:58 AM, Daniel Borkmann wrote:
On 08/04/2017 07:46 AM, Joel Fernandes wrote:
When cross-compiling the bpf sample map_perf_test for aarch64, I find that
__NR_getpgrp is undefined. This causes build errors. Fix it by allowing
On Fri, Aug 4, 2017 at 6:58 AM, Daniel Borkmann wrote:
> On 08/04/2017 07:46 AM, Joel Fernandes wrote:
>>
>> When cross-compiling the bpf sample map_perf_test for aarch64, I find that
>> __NR_getpgrp is undefined. This causes build errors. Fix it by allowing
>> the
>> deprecated syscall in the sam
From: Yunsheng Lin
Date: Fri, 4 Aug 2017 17:24:59 +0800
> This patch fixes the __udivdi3 undefined error reported by
> test robot.
>
> Fixes: b8c17f708831 ("net: hns: Add self-adaptive interrupt coalesce support
> in hns driver")
> Signed-off-by: Yunsheng Lin
Applied, thank you.
On 08/04/2017 07:46 AM, Joel Fernandes wrote:
When cross-compiling the bpf sample map_perf_test for aarch64, I find that
__NR_getpgrp is undefined. This causes build errors. Fix it by allowing the
deprecated syscall in the sample.
Signed-off-by: Joel Fernandes
---
samples/bpf/map_perf_test_us
This patch fixes the __udivdi3 undefined error reported by
test robot.
Fixes: b8c17f708831 ("net: hns: Add self-adaptive interrupt coalesce support in
hns driver")
Signed-off-by: Yunsheng Lin
---
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(
When cross-compiling the bpf sample map_perf_test for aarch64, I find that
__NR_getpgrp is undefined. This causes build errors. Fix it by allowing the
deprecated syscall in the sample.
Signed-off-by: Joel Fernandes
---
samples/bpf/map_perf_test_user.c | 2 ++
1 file changed, 2 insertions(+)
dif
to linux build tree
make.cross ARCH=cris
All errors (new ones prefixed by >>):
(post_inc:SI (reg:SI 15 acr))
net/core/rtnetlink.c: In function 'rtnl_fill_vfinfo':
>> net/core/rtnetlink.c:1234:1: internal compiler error: output_operand:
>> unrecognized add
DEP_TRUE (use (reg:SI 4 r4))
(expr_list:REG_DEP_TRUE (use (reg:SI 3 r3))
(nil
>> drivers/scsi/fcoe/fcoe_ctlr.c:3097:1: internal compiler error: in
>> reload_cse_simplify_operands, at postreload.c:396
Please submit a full bug report,
with preprocessed source if a
On Thu, Sep 29, 2016 at 06:46:57PM +0200, Cyrille Pitchen wrote:
> This patch fixes a compiler error when VERBOSE_DEBUG is defined. Indeed,
> in atmel_aes_write(), the 3rd argument of atmel_aes_reg_name() was
> missing.
>
> Signed-off-by: Cyrille Pitchen
> Reported-by: Le
This patch fixes a compiler error when VERBOSE_DEBUG is defined. Indeed,
in atmel_aes_write(), the 3rd argument of atmel_aes_reg_name() was
missing.
Signed-off-by: Cyrille Pitchen
Reported-by: Levent Demir
---
drivers/crypto/atmel-aes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
the attached .config to linux build tree
make.cross ARCH=cris
All errors (new ones prefixed by >>):
(post_inc:SI (reg:SI 15 acr))
net/ipv4/fib_semantics.c: In function 'fib_create_info':
>> net/ipv4/fib_semantics.c:1219:1: internal compiler error: output_ope
ogic/qlge/qlge_main.c:4691 287 {*lea64}
(nil))
>> drivers/net/ethernet/qlogic/qlge/qlge_main.c:4813:1: internal compiler
>> error: in extract_constrain_insn, at recog.c:2190
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
The commit 41840d211c51 ("perf config: Move config declarations from
util/cache.h to util/config.h") moved perf_config*(), causes the
following errors when we build with LIBBABELTRACE=1:
util/data-convert-bt.c: In function ‘convert__config’:
util/data-convert-bt.c:1269:3: error: implicit decla
3.13.11-ckt16 -stable review patch. If anyone has any objections, please let
me know.
--
From: John David Anglin
commit 45db07382a5c78b0c43b3b0002b63757fb60e873 upstream.
The __ldcw macro has a problem when its argument needs to be reloaded from
memory. The output memory oper
mit bc0c5aa35ac88342831933ca7758ead62d9bae2b introduces a
> > compiler error in some platforms.
> >
> > /home/hans/work/build/media_build/v4l/ir-hix5hd2.c: In function
> > 'hix5hd2_ir_config':
> > /home/hans/work/build/media_build/v4l/ir-hix5hd2.c:95:2: error: im
On 02/16/2015 01:18 PM, Luis de Bethencourt wrote:
> Hi all,
>
> As can be seen in Han's build log:
> http://hverkuil.home.xs4all.nl/logs/Saturday.log
>
> The recent commit bc0c5aa35ac88342831933ca7758ead62d9bae2b introduces a
> compiler error in some platforms.
Hi all,
As can be seen in Han's build log:
http://hverkuil.home.xs4all.nl/logs/Saturday.log
The recent commit bc0c5aa35ac88342831933ca7758ead62d9bae2b introduces a
compiler error in some platforms.
/home/hans/work/build/media_build/v4l/ir-hix5hd2.c: In function
'hix5hd2_ir_config&#x
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: John David Anglin
commit 45db07382a5c78b0c43b3b0002b63757fb60e873 upstream.
The __ldcw macro has a problem when its argument needs to be reloaded from
memory. The output memory operand and the
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: John David Anglin
commit 45db07382a5c78b0c43b3b0002b63757fb60e873 upstream.
The __ldcw macro has a problem when its argument needs to be reloaded from
memory. The output memory operand and the
3.16.7-ckt4 -stable review patch. If anyone has any objections, please let me
know.
--
From: John David Anglin
commit 45db07382a5c78b0c43b3b0002b63757fb60e873 upstream.
The __ldcw macro has a problem when its argument needs to be reloaded from
memory. The output memory operan
On 20/10/14 20:52, Dan Murphy wrote:
> Fix the compiler error when the CONFIG_PM_OPS flag is not set.
>
> drivers/iio/light/tsl4531.c:235:8: error: ‘tsl4531_suspend’ undeclared here
> (not in a function)
> drivers/iio/light/tsl4531.c:235:8: error: ‘tsl4531_resume’ undeclared he
Fix the compiler error when the CONFIG_PM_OPS flag is not set.
drivers/iio/light/tsl4531.c:235:8: error: ‘tsl4531_suspend’ undeclared here
(not in a function)
drivers/iio/light/tsl4531.c:235:8: error: ‘tsl4531_resume’ undeclared here (not
in a function)
Signed-off-by: Dan Murphy
---
drivers
On Thu, Jul 19, 2012 at 04:53:26PM -0400, Daniel Wisehart wrote:
> Hello Kent,
>
> This patch keeps gcc 4.7.0 happy. The static function dump_bset() could be
> moved, but that would have made a bigger patch. :-)
Thanks! dump_bset() does need to be moved so it's available if DEBUG or
EDEBUG ar
Hello Kent,
This patch keeps gcc 4.7.0 happy. The static function dump_bset() could be
moved, but that would have made a bigger patch. :-)
Thanks,
Daniel
diff --git a/drivers/md/bcache/debug.c b/drivers/md/bcache/debug.c
index 3c9c24d..4dc0ba5 100644
--- a/drivers/md/bcache/debug.c
+++ b/d
Argh. Who runs with CONFIG_HUGETLB_PAGE not set anyway ;)
Acked-by: Adam Litke <[EMAIL PROTECTED]>
On Sat, 2007-11-10 at 19:54 -0500, Erez Zadok wrote:
> Using http://userweb.kernel.org/~akpm/mmotm/ timestamped "10-Nov-2007
> 22:46". CONFIG_HUGETLB_PAGE not set.
>
> $ make
> CC mm/memory
Using http://userweb.kernel.org/~akpm/mmotm/ timestamped "10-Nov-2007
22:46". CONFIG_HUGETLB_PAGE not set.
$ make
CC mm/memory.o
mm/memory.c:1040:29: error: macro "follow_hugetlb_page" passed 8 arguments, but
takes just 7
mm/memory.c: In function 'get_user_pages':
mm/memory.c:1039: error:
Renato S. Yamane escreveu:
$ make xconfig
HOSTCC scripts/basic/fixdep
scripts/basic/fixdep.c: In function ‘parse_dep_file’:
scripts/basic/fixdep.c:399: internal compiler error: segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org
Jesper Juhl escreveu:
On 27/08/07, Renato S. Yamane <[EMAIL PROTECTED]> wrote:
Can someone help me with this?
$ make xconfig
HOSTCC scripts/basic/fixdep
scripts/basic/fixdep.c: In function 'parse_dep_file':
scripts/basic/fixdep.c:399: internal compiler error: segmentation fau
On 27/08/07, Renato S. Yamane <[EMAIL PROTECTED]> wrote:
> Can someone help me with this?
>
> $ make xconfig
> HOSTCC scripts/basic/fixdep
> scripts/basic/fixdep.c: In function 'parse_dep_file':
> scripts/basic/fixdep.c:399: internal compiler error: segmentatio
In 7d12e780e003f93433d49ce78cfedf4b4c52adc5 David Howells performed
this evolution:
"IRQ: Maintain regs pointer globally rather than passing to IRQ handlers"
He correctly updated many of the function definitions that were using
this extra regs pointer parameter but forgot to update some caller
from drivers/scsi/lpfc/lpfc_sli.c:23:
> include/linux/pci.h:251: internal compiler error: in build_int_cst_wide,
> at tree.c:803
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> For Debi
Hello !
I'm triyng to compile the kernel 2.6.19 on Debian Testing 4.0
Unfortunately, I can't success.
This is my error message :
CC [M] drivers/scsi/lpfc/lpfc_sli.o
In file included from drivers/scsi/lpfc/lpfc_sli.c:23:
include/linux/pci.h:251: internal compiler error: in build_in
I've the following compiler error:
linux-2.6.20.i686/arch/i386/mm/pgtable.c:303: undefined reference to
`paravirt_enabled'
linux-2.6.20.i686/arch/i386/mm/pgtable.c:306: undefined reference to `hypercall'
Error 1
Is there anyone who knows what causes this error?
Henri
-
To unsubs
On Fri, Dec 08, Jeremy Fitzhardinge wrote:
> So why don't I have arch/ppc/include/asm/bug.h in my tree here?
Most likely because you still do not build with 'make O=$somedir'.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
M
Meelis Roos wrote:
>> Hm, what's your .config?
>>
>
> Below. It's a PReP machine so using the old ppc arch.
>
>
>> Hey, what's arch/pps/include/asm/bug.h? Is your tree clean?
>>
>
> Tree is clean
So why don't I have arch/ppc/include/asm/bug.h in my tree here?
It does look like the p
> Hm, what's your .config?
Below. It's a PReP machine so using the old ppc arch.
> Hey, what's arch/pps/include/asm/bug.h? Is your tree clean?
Tree is clean except a local in-progress patch against cirrusfb and
another against net/ipv6/ndisc.c that made 2.6.19 work, nothing unclean
about head
Meelis Roos wrote:
> This if from todays git (2006-12-08):
>
> CC arch/ppc/kernel/asm-offsets.s
> In file included from arch/ppc/include/asm/bug.h:97,
> from include/linux/kernel.h:18,
> from include/asm/system.h:7,
> from include/linux/list
This if from todays git (2006-12-08):
CC arch/ppc/kernel/asm-offsets.s
In file included from arch/ppc/include/asm/bug.h:97,
from include/linux/kernel.h:18,
from include/asm/system.h:7,
from include/linux/list.h:9,
from incl
Ive also had a problem with signal 11, heres a great page explaining the aspects of
signal 11 error from gcc (http://www.bitwizard.nl/sig11/).
Signal 11 is usually a hardware problem, as the article points out. I found a sloppy
soulution playing with my BIOS settings, turns out there was an opt
Hi Peter.
Wasn't 2.2.12 the kernel that included the `lock halt` bug patch?
>>> Perhaps, but is has absolutely nothing to do with the rest of
>>> this discussion.
>> The `lock halt` bug patch was specific to the Cyrix processors
>> (not to be confused with the `lock registers` patch f
Riley Williams wrote:
> Hi Peter.
>
> >> Wasn't 2.2.12 the kernel that included the `lock halt` bug patch?
>
> > Perhaps, but is has absolutely nothing to do with the rest of
> > this discussion.
>
> The `lock halt` bug patch was specific to the Cyrix processors (not to
> be confused with t
Hi Peter.
>> Wasn't 2.2.12 the kernel that included the `lock halt` bug patch?
> Perhaps, but is has absolutely nothing to do with the rest of
> this discussion.
The `lock halt` bug patch was specific to the Cyrix processors (not to
be confused with the `lock registers` patch for the Intel p
Riley Williams wrote:
>
> Wasn't 2.2.12 the kernel that included the `lock halt` bug patch?
>
Perhaps, but is has absolutely nothing to do with the rest of this
discussion.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
Hi HPA.
>> Some time ago I installed Linux (Redhat 6.0) on my pc (Cx486 8M
>> RAM) and gcc had a lot of signal 11 (a couple every hour) I was
>> upgrading the kernel every time there was a new kernel and from
>> 2.2.12(or 14) no more signal 11 (very rare) Is this still a
>> hardware problem
Followup to: <[EMAIL PROTECTED]>
By author:szonyi calin <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Almost always ?
> It seems like gcc is THE ONLY program which gets
> signal 11
> Why the X server doesn't get signal 11 ?
> Why others programs don't get signal 11 ?
>
gcc happens
> Almost always ?
> It seems like gcc is THE ONLY program which gets
> signal 11
> Why the X server doesn't get signal 11 ?
> Why others programs don't get signal 11 ?
...
> Some time ago I installed Linux (Redhat 6.0) on my
> pc (Cx486 8M RAM) and gcc had a lot of signal 11 (a
> couple every hou
- Received message begins Here -
>
>
> --- Jesse Pollard <[EMAIL PROTECTED]>
> wrote:
> > >
> > >
> > > "This is almost always the result of flakiness in
> > your hardware - either
> > > RAM (most likely), or motherboard (less likely).
> > "
> > >
At 10:20 AM 6/29/01, you wrote:
>Almost always ?
>It seems like gcc is THE ONLY program which gets
>signal 11
>Why the X server doesn't get signal 11 ?
>Why others programs don't get signal 11 ?
>
>I remember that once Bill Gates was asked about
>crashes in windows and he said: It's a hardware
>p
--- Jesse Pollard <[EMAIL PROTECTED]>
wrote:
> >
> >
> > "This is almost always the result of flakiness in
> your hardware - either
> > RAM (most likely), or motherboard (less likely).
> "
> >
> > I cannot understand
> this. There are man
>
>
> "This is almost always the result of flakiness in your hardware - either
> RAM (most likely), or motherboard (less likely). "
>
> I cannot understand this. There are many other
> stuffs that I compiled with gcc without any problem. A
On Thu, Jun 28, 2001 at 11:23:37PM -0600, Blesson Paul wrote:
>
> "This is almost always the result of flakiness in your hardware - either
> RAM (most likely), or motherboard (less likely). "
>
> I cannot understand this. There are many oth
"This is almost always the result of flakiness in your hardware - either
RAM (most likely), or motherboard (less likely). "
I cannot understand this. There are many other
stuffs that I compiled with gcc without any problem. Again compilatio
hi
I am trying to compile the kernel2.4.5 source code.
Presently I have kernel2.2.14 and Redhat6.2. I have egcs1.2.2. Now when I
compile I will get the following error
gcc: Internel compiler error: program cc1 got fatal signal 11
make Error 1
Leaving directory
Hi,
Pls. send your .config file as well, along with architecture (and
compiler/glibc/distribution name and version).
Masoud.
(It enables everyone to reproduce the problem).
Nico Blanke wrote:
>
> Hi there !
>
> I'm not able to compile linux 2.4.4, because i get the following
Hi there !
I'm not able to compile linux 2.4.4, because i get the following
compiler-error :
buz.c: In function `v4l_fbuffer_alloc':
buz.c:188: `KMALLOC_MAXSIZE' undeclared (first use in this function)
buz.c:188: (Each undeclared identifier is reported only once
buz.c:188: fo
Blah. Puke. Ug. Not your changes, Bart... which are ok, but
incomplete.
Here is the complete bugfix. There are two places where error
conditions are not fully handled, and 'out_spin' can kfree(image),
saving some code. The worst bug of the list... if the firmware
copy_from_user failed w
On Fri, 10 Nov 2000, Alan Cox wrote:
> > rrunner.c : In function 'rr_ioctl'
> > rrunner.c:1558: label 'out' used but not defined
> > make[2]: *** [rrunner.o] Error 1
>
> My fault. Swap that 1158 line pair
>
> error = -EPERM;
> goto out;
>
> with
> ret
> rrunner.c : In function 'rr_ioctl'
> rrunner.c:1558: label 'out' used but not defined
> make[2]: *** [rrunner.o] Error 1
My fault. Swap that 1158 line pair
error = -EPERM;
goto out;
with
return -EPERM
-
To unsubscribe from this list: send the
Hello,
I received the following error while compiling test11-pre2:
rrunner.c : In function 'rr_ioctl'
rrunner.c:1558: label 'out' used but not defined
make[2]: *** [rrunner.o] Error 1
make[2]: Leaving directory '/usr/src/linux/drivers/net'
...
make: ** [mod_drivers] Error 2
out is located in t
73 matches
Mail list logo
