This fixes a bug that we treat all sequencer operations as ands and
never do the additional invalid bit checks non-and operations require
because the if () to determine this has an operand which is always
true at the end of the or statement.
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Acked-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
If a prefix is selected for flex, we should be using it everywhere.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
On Tue, 2007-05-22 at 06:51 -0500, Bob Tracy wrote:
> Second try: originally reported this back on April 17th. 2.6.X
> kernel builds started failing after I upgraded my compiler from
> gcc-3.3.X to gcc-3.4.6:
>
> make -C drivers/scsi/aic7xxx/aicasm
> (...)
> gcc -I/usr/include -I. aicasm.c aicasm_symbol.c aicasm_gram.c aicasm_macro_gram.c aicasm_scan.c aicasm_macro_scan.c -o aicasm -ldb
> aicasm_gram.y:1948: error: conflicting types for 'yyerror'
> aicasm_gram.tab.c:3004: error: previous implicit declaration of 'yyerror' was here
> aicasm_macro_gram.y:162: error: conflicting types for 'mmerror'
> aicasm_macro_gram.tab.c:1196: error: previous implicit declaration of 'mmerror' was here
Fix is to add a prototype for yyerror and mmerror to the relevant files.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
When we introduced -rR then aic7xxx no loger could pick up definition
of YACC&LEX from make - so do it explicit now.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Rebuild the aic7xxx firmware doesn't work anymore after this change
which appeared int 2.6.13-rc1:
[SCSI] aic7xxx/aic79xx: remove useless byte order macro cruft
Two files did not include byteorder.h, resulting in aic dying with a panic
"Unknown opcode encountered in seq program"
This fixes it for me.
Signed-off-by: Olaf Hering <olh@suse.de>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
