2.4.2-pre1

2.4.2-pre1

[Linus Torvalds]

Mainly a number of small details and some driver updates. The socket
datagram handling one is important, and has already been posted separately
here on linux-kernel. The VIA driver update is rather important if you
have one of the newer VIA chipsets.

		Linus

----
-pre1:
 - XMM: don't allow illegal mxcsr values
 - ACPI: handle non-existent battery strings gracefully
 - Compaq Smart Array driver update
 - Kanoj Sarcar: serial console hardware flow control support
 - ide-cs: revert toc-valid cache checking in 2.4.1
 - Vojtech Pavlik: update via82cxxx driver to handle the vt82c686
 - raid5 graceful failure handling fix
 - ne2k-pci: enable device before asking the irq number
 - sis900 driver update
 - riva FB driver update
 - fix silly inode hashing pessimization
 - add SO_ACCEPTCONN for SuS
 - remove modinfo hack workaround, all newer modutils do it correctly
 - datagram socket shutdown fix
 - mark process as running when it takes a page-fault

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.2-pre1

[Tom Rini]

On Sat, Feb 03, 2001 at 08:24:27PM -0800, Linus Torvalds wrote:

...
> -pre1:
...
>  - riva FB driver update

Er, what exactly is the CONFIG_PREP stuff in this driver supposed to be
for?  "CONFIG_PREP" doesn't exist anymore to start with, and secondly I'm
not sure if any PReP boxes ever shipped with a riva card to start with.  The
only real way to handle this in 2.4 is something like:
#ifdef CONFIG_ALL_PPC /* CHRP/PMAC/PREP */
#include <asm/processor.h>
#define isPReP (_machine == _MACH_prep)
#else
#define isPReP 0
#endif

That is, if there's really any need to test explicitly for a PReP box.
I asked Ani Joshi about this a while ago, and he wasn't quite sure why they
were in there either..

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.2-pre1

[Jeff Garzik]

Tom Rini wrote:
> Er, what exactly is the CONFIG_PREP stuff in this driver supposed to be
> for?  "CONFIG_PREP" doesn't exist anymore to start with, and secondly I'm
> not sure if any PReP boxes ever shipped with a riva card to start with.  The
> only real way to handle this in 2.4 is something like:
> #ifdef CONFIG_ALL_PPC /* CHRP/PMAC/PREP */
> #include <asm/processor.h>
> #define isPReP (_machine == _MACH_prep)
> #else
> #define isPReP 0
> #endif
> 
> That is, if there's really any need to test explicitly for a PReP box.
> I asked Ani Joshi about this a while ago, and he wasn't quite sure why they
> were in there either..

It looks like it might have come from drivers/video/clgenfb.c, perhaps
for use with big endian framebuffers?

If the driver works on PPC without CONFIG_PREP code, let's get rid of
it.

	Jeff


-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.2-pre1

[Tom Rini]

On Tue, Feb 06, 2001 at 01:52:36PM -0500, Jeff Garzik wrote:
> Tom Rini wrote:
> > Er, what exactly is the CONFIG_PREP stuff in this driver supposed to be
> > for?  "CONFIG_PREP" doesn't exist anymore to start with, and secondly I'm
> > not sure if any PReP boxes ever shipped with a riva card to start with.  The
> > only real way to handle this in 2.4 is something like:
> > #ifdef CONFIG_ALL_PPC /* CHRP/PMAC/PREP */
> > #include <asm/processor.h>
> > #define isPReP (_machine == _MACH_prep)
> > #else
> > #define isPReP 0
> > #endif
> > 
> > That is, if there's really any need to test explicitly for a PReP box.
> > I asked Ani Joshi about this a while ago, and he wasn't quite sure why they
> > were in there either..
> 
> It looks like it might have come from drivers/video/clgenfb.c, perhaps
> for use with big endian framebuffers?

It is indeed from clgen, but even there it's only needed on the PReP boxes
with a cirrus logic card.  The MacPicasso cards (also clgen) need some other
magic (see linux-fbdev).

> If the driver works on PPC without CONFIG_PREP code, let's get rid of
> it.

Well, it's definatly not doing anything now.  It probably shouldn't be there
anyways, as in clgen it seems to be for PReP black magic.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.2-pre1

[Linus Torvalds]

[ Linux-kernel added to the cc, as others probably also wonder ]

On Sat, 3 Feb 2001, David D.W. Downey wrote:
>
> 	How often does Alan's patches get rolled into your main line? I'm
> having difficulty following the divergence here. I'm trying to run THE
> latest release(s) of your kernel with applicaple patches. I'm just trying
> to figure out if everything that is in the ac## line is ALWAYS rolled into
> your pre## line or not. Which patch sequence am I supposed to follow to
> have THE most current release of all fixes et. al.?

Alan tends to have much more experimental patches than I do - and we don't
sync up more often than maybe once a month or so. And even then, the
sync-up won't be complete, exactly because I don't take the experimental
parts (or more accurately, Alan mostly doesn't even try to send them to me
and we tend to agree pretty well on what is appropriate and what is not).

We're nearing another sync-point right now - I actually have a lot of
Alans patches in my mail-box, and -pre2 will probably contain a lot of the
-ac stuff. But don't expect a complete sync, as explained above.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/