Re: __bad_udelay in 2.2.18pre15
On Wed, Oct 11, 2000 at 12:13:48PM +0200, Benjamin Herrenschmidt wrote: > >Well, at first, I wanted to implement it the same way on PPC. However, it > >dies on all occurences where udelay is called with a non-constant expression. > > > >I spotted this case in a few PPC specific stuffs (fixable), but also in > >the sys_nanosleep code, and in the de4x5 driver. > > Hrm... looks like I missed the story about the __builtin_constant_p(). Is > this a gcc-specific built-in feature ? Like all __builtin_* functions. It returns 1 if the compiler is able to figure out that the argument is a constant expression, 0 otherwise. See include/asm-i386/io.h for particular beautyfull examples ... Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
> Wouldn't it be better to use an #error directive? I'm sure this could turn > into a FAQ, even though the symbol is called "__bad_udelay()". You cant do that trick since #error is pre-processor, otherwise - yes > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
> >Yep. This is a huge release patch anyway so resynching the stuff is fine. >What I wont take is stuff touching core code I do have a 2 lines patch to the common ide code that fix a problem when revalidating a CD-ROM after sleep, but it was ack'ed by Andre Hedrick. I also have a two-liners to kernel/printk.c to allow takeover of my boot console by the real vt subsystem (I found no way for a struct consw to take over a struct console without this patch). I'll make sure those are separate from the main patch set. I need some time to do some polishing and slicing all those patches so you don't get a single hundreds kb diff, expect something around this week-end. I leave out some fbdev stuffs that may cause problems with other archs. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
"Chris Swiedler" <[EMAIL PROTECTED]> writes: |> > > 2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : |> > > extern void __bad_udelay(void); |> > > |> > > #define udelay(n) (__builtin_constant_p(n) ? \ |> > > ((n) > 2 ? __bad_udelay() : __const_udelay((n) * |> > > 0x10c6ul)) : \ |> > > __udelay(n)) |> > > |> > > ... |> > > It seems __bad_udelay is not defined anywhere in the kernel source. |> > |> > Correct. Its a compile time error trap |> |> Wouldn't it be better to use an #error directive? There is no way to test the condition in the preprocessor. Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: __bad_udelay in 2.2.18pre15
> > 2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : > > extern void __bad_udelay(void); > > > > #define udelay(n) (__builtin_constant_p(n) ? \ > > ((n) > 2 ? __bad_udelay() : __const_udelay((n) * > > 0x10c6ul)) : \ > > __udelay(n)) > > > > ... > > It seems __bad_udelay is not defined anywhere in the kernel source. > > Correct. Its a compile time error trap Wouldn't it be better to use an #error directive? I'm sure this could turn into a FAQ, even though the symbol is called "__bad_udelay()". chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
> later, I have to extract them from my tree. Well... would you accept a > huge pile of PPC patches for 2.2.18 in this case, I can send you my > current diffs (with a bit of cleanup) ? Yep. This is a huge release patch anyway so resynching the stuff is fine. What I wont take is stuff touching core code > Those contain almost only pmac-specific stuffs (support for new machines, > sleep fixes, and a few more fixes here or there). Ok - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
>> >> Well, at first, I wanted to implement it the same way on PPC. However, it >> dies on all occurences where udelay is called with a non-constant >expression. > >__builtin_constant_p means non constant expressions will always call udelay > >> I spotted this case in a few PPC specific stuffs (fixable), but also in >> the sys_nanosleep code, and in the de4x5 driver. > >I'll check these two Forget about them. It was my non-understanding of __builtin_constant_p() that was causing me the problem. I fixed a few >2 udelay's (replacing them with mdelay) in some PPC specific code. I'll send you some patches later, I have to extract them from my tree. Well... would you accept a huge pile of PPC patches for 2.2.18 in this case, I can send you my current diffs (with a bit of cleanup) ? Those contain almost only pmac-specific stuffs (support for new machines, sleep fixes, and a few more fixes here or there). Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
> >> #define udelay(n) (__builtin_constant_p(n) ? \ > >> ((n) > 2 ? __bad_udelay() : __const_udelay((n) * > >> 0x10c6ul)) : \ > >> __udelay(n)) > >> > >> ... > >> It seems __bad_udelay is not defined anywhere in the kernel source. > > > >Correct. Its a compile time error trap > > Well, at first, I wanted to implement it the same way on PPC. However, it > dies on all occurences where udelay is called with a non-constant expression. __builtin_constant_p means non constant expressions will always call udelay > I spotted this case in a few PPC specific stuffs (fixable), but also in > the sys_nanosleep code, and in the de4x5 driver. I'll check these two - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
>Well, at first, I wanted to implement it the same way on PPC. However, it >dies on all occurences where udelay is called with a non-constant expression. > >I spotted this case in a few PPC specific stuffs (fixable), but also in >the sys_nanosleep code, and in the de4x5 driver. Hrm... looks like I missed the story about the __builtin_constant_p(). Is this a gcc-specific built-in feature ? Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
>> 2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : >> extern void __bad_udelay(void); >> >> #define udelay(n) (__builtin_constant_p(n) ? \ >> ((n) > 2 ? __bad_udelay() : __const_udelay((n) * >> 0x10c6ul)) : \ >> __udelay(n)) >> >> ... >> It seems __bad_udelay is not defined anywhere in the kernel source. > >Correct. Its a compile time error trap Well, at first, I wanted to implement it the same way on PPC. However, it dies on all occurences where udelay is called with a non-constant expression. I spotted this case in a few PPC specific stuffs (fixable), but also in the sys_nanosleep code, and in the de4x5 driver. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : extern void __bad_udelay(void); #define udelay(n) (__builtin_constant_p(n) ? \ ((n) 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \ __udelay(n)) ... It seems __bad_udelay is not defined anywhere in the kernel source. Correct. Its a compile time error trap Well, at first, I wanted to implement it the same way on PPC. However, it dies on all occurences where udelay is called with a non-constant expression. I spotted this case in a few PPC specific stuffs (fixable), but also in the sys_nanosleep code, and in the de4x5 driver. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
Well, at first, I wanted to implement it the same way on PPC. However, it dies on all occurences where udelay is called with a non-constant expression. I spotted this case in a few PPC specific stuffs (fixable), but also in the sys_nanosleep code, and in the de4x5 driver. Hrm... looks like I missed the story about the __builtin_constant_p(). Is this a gcc-specific built-in feature ? Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
#define udelay(n) (__builtin_constant_p(n) ? \ ((n) 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \ __udelay(n)) ... It seems __bad_udelay is not defined anywhere in the kernel source. Correct. Its a compile time error trap Well, at first, I wanted to implement it the same way on PPC. However, it dies on all occurences where udelay is called with a non-constant expression. __builtin_constant_p means non constant expressions will always call udelay I spotted this case in a few PPC specific stuffs (fixable), but also in the sys_nanosleep code, and in the de4x5 driver. I'll check these two - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
Well, at first, I wanted to implement it the same way on PPC. However, it dies on all occurences where udelay is called with a non-constant expression. __builtin_constant_p means non constant expressions will always call udelay I spotted this case in a few PPC specific stuffs (fixable), but also in the sys_nanosleep code, and in the de4x5 driver. I'll check these two Forget about them. It was my non-understanding of __builtin_constant_p() that was causing me the problem. I fixed a few 2 udelay's (replacing them with mdelay) in some PPC specific code. I'll send you some patches later, I have to extract them from my tree. Well... would you accept a huge pile of PPC patches for 2.2.18 in this case, I can send you my current diffs (with a bit of cleanup) ? Those contain almost only pmac-specific stuffs (support for new machines, sleep fixes, and a few more fixes here or there). Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
later, I have to extract them from my tree. Well... would you accept a huge pile of PPC patches for 2.2.18 in this case, I can send you my current diffs (with a bit of cleanup) ? Yep. This is a huge release patch anyway so resynching the stuff is fine. What I wont take is stuff touching core code Those contain almost only pmac-specific stuffs (support for new machines, sleep fixes, and a few more fixes here or there). Ok - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
"Chris Swiedler" [EMAIL PROTECTED] writes: | 2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : | extern void __bad_udelay(void); | | #define udelay(n) (__builtin_constant_p(n) ? \ | ((n) 2 ? __bad_udelay() : __const_udelay((n) * | 0x10c6ul)) : \ | __udelay(n)) | | ... | It seems __bad_udelay is not defined anywhere in the kernel source. | | Correct. Its a compile time error trap | | Wouldn't it be better to use an #error directive? There is no way to test the condition in the preprocessor. Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
Yep. This is a huge release patch anyway so resynching the stuff is fine. What I wont take is stuff touching core code I do have a 2 lines patch to the common ide code that fix a problem when revalidating a CD-ROM after sleep, but it was ack'ed by Andre Hedrick. I also have a two-liners to kernel/printk.c to allow takeover of my boot console by the real vt subsystem (I found no way for a struct consw to take over a struct console without this patch). I'll make sure those are separate from the main patch set. I need some time to do some polishing and slicing all those patches so you don't get a single hundreds kb diff, expect something around this week-end. I leave out some fbdev stuffs that may cause problems with other archs. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
Wouldn't it be better to use an #error directive? I'm sure this could turn into a FAQ, even though the symbol is called "__bad_udelay()". You cant do that trick since #error is pre-processor, otherwise - yes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
On Wed, Oct 11, 2000 at 12:13:48PM +0200, Benjamin Herrenschmidt wrote: Well, at first, I wanted to implement it the same way on PPC. However, it dies on all occurences where udelay is called with a non-constant expression. I spotted this case in a few PPC specific stuffs (fixable), but also in the sys_nanosleep code, and in the de4x5 driver. Hrm... looks like I missed the story about the __builtin_constant_p(). Is this a gcc-specific built-in feature ? Like all __builtin_* functions. It returns 1 if the compiler is able to figure out that the argument is a constant expression, 0 otherwise. See include/asm-i386/io.h for particular beautyfull examples ... Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
Marcelo Tosatti <[EMAIL PROTECTED]> said: > 2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : > > ... > > extern void __bad_udelay(void); > > ... > > #define udelay(n) (__builtin_constant_p(n) ? \ > ((n) > 2 ? __bad_udelay() : __const_udelay((n) * > 0x10c6ul)) : \ > __udelay(n)) > > ... > > > It seems __bad_udelay is not defined anywhere in the kernel source. That is precisely the idea: Flag the places where udelay() is called with a large constant value. Just won't find out uses with large _variable_ arguments, but it is a start. Netted one in PCMCIA-CS... -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
> 2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : > extern void __bad_udelay(void); > > #define udelay(n) (__builtin_constant_p(n) ? \ > ((n) > 2 ? __bad_udelay() : __const_udelay((n) * > 0x10c6ul)) : \ > __udelay(n)) > > ... > It seems __bad_udelay is not defined anywhere in the kernel source. Correct. Its a compile time error trap - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
Marcelo Tosatti <[EMAIL PROTECTED]> writes: > 2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : > > ... > > extern void __bad_udelay(void); > > ... > > #define udelay(n) (__builtin_constant_p(n) ? \ > ((n) > 2 ? __bad_udelay() : __const_udelay((n) * > 0x10c6ul)) : \ > __udelay(n)) > > ... > > > It seems __bad_udelay is not defined anywhere in the kernel source. Which is the whole point - you wouldn't want to call a bad function, would you? If you reference __bad_udelay() you are doing something wrong and should be using mdelay() instead. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 452062 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
__bad_udelay in 2.2.18pre15
2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : ... extern void __bad_udelay(void); ... #define udelay(n) (__builtin_constant_p(n) ? \ ((n) > 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \ __udelay(n)) ... It seems __bad_udelay is not defined anywhere in the kernel source. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
__bad_udelay in 2.2.18pre15
2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : ... extern void __bad_udelay(void); ... #define udelay(n) (__builtin_constant_p(n) ? \ ((n) 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \ __udelay(n)) ... It seems __bad_udelay is not defined anywhere in the kernel source. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
Marcelo Tosatti [EMAIL PROTECTED] writes: 2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : ... extern void __bad_udelay(void); ... #define udelay(n) (__builtin_constant_p(n) ? \ ((n) 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \ __udelay(n)) ... It seems __bad_udelay is not defined anywhere in the kernel source. Which is the whole point - you wouldn't want to call a bad function, would you? If you reference __bad_udelay() you are doing something wrong and should be using mdelay() instead. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 452062 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : extern void __bad_udelay(void); #define udelay(n) (__builtin_constant_p(n) ? \ ((n) 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \ __udelay(n)) ... It seems __bad_udelay is not defined anywhere in the kernel source. Correct. Its a compile time error trap - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
Marcelo Tosatti [EMAIL PROTECTED] said: 2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : ... extern void __bad_udelay(void); ... #define udelay(n) (__builtin_constant_p(n) ? \ ((n) 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \ __udelay(n)) ... It seems __bad_udelay is not defined anywhere in the kernel source. That is precisely the idea: Flag the places where udelay() is called with a large constant value. Just won't find out uses with large _variable_ arguments, but it is a start. Netted one in PCMCIA-CS... -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
