Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>

Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>

Because in6_dev_get() fails during device deletion,
we failed to leave solicited-node multicast address.
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>

Use __ipv6_dev_mc_dec() instead where the caller knows idev.
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>

dev is unused in the function.
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>

Case 1: if net.ipv6.conf.IFACE.forwarding has been set to 1,
we multiply join routers' multicast/anycast addresses 
by setting net.ipv6.conf.all.forwarding to 1.

Noticed by Andre Tomt <andre@tomt.net>.

Case 2: if we change net.ipv6.conf.FOO.forwarding from 1 to 2,
we multiply join routers' multicast/anycast addresses.
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>

We failed to leave all-routers multicast address.
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>

The code re-allocating new bus resources in case of conflicts use a
function called probe_resource(), which has a typo (spotted by the
uninitialized variable use of gcc) causing it to potentially return
bogus results. This fixes it:
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The changes to prom_init/offb interaction introduced by the ppc64
monster cleanup patch need a fix to ppc32 prom_init so that offb
works again. ppc32 prom_init() could use a lot more cleanup, but
let's do the minimal fix to make it work now.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The recent ppc64 changes for offb introduced an uninitialized pointer
use for ppc32, here's the fix:
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

A typo in pmac_feature.c can cause us to use a bogus node pointer when
iterating the i2c controllers during boot. Fortunately, it seems that
we always find the one we are looking for first, and thus never ended
up in an inifinite loop here, but let's fix it and fix the warning at
the same time.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

In chrp_setup.c, chrp_int_ack could be left uninitialized and passed
"as-is" to i8259_init() if the OF node for the 8259 wasn't found.  I
don't know if that should happen, but the i8259 code can deal with
int_ack beeing 0, so let's be safe, initialize it, and remove a warning
at the same time. 
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

There's an obvious uninitialized return value in pmac_cpufreq, here's
a fix:
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

When pci_assign_all_busses is set, the common code will re-assign all
the bus numbers, which we still need to do one various pmacs, at least
until XFree/XOrg understands PCI domains properly.  However, this
process triggers a bug if during this renumbering, on a given segment, a
P2P bridge not yet renumbered has conflicting downstream bus range with
a P2P bridge just renumbered.  The probing will just behave randomly and
either miss devices, show duplicates, or just lockup in some
circumstances.  This is typically triggered on Apple Xserve G4s who have
at least 2 P2P bridges built-in on the same segment of the first PCI
(non-AGP) domain

The "workaround" we use on pmac that was in my tree for a while but got
"lost" during the big merge a while ago is to offset the bus numbers
between domains by 16.  This avoids the above collision scenario in all
practical cases.

The long term solution of course is to stop renumbering and make sure
that all drivers are domain safe (there may be a couple issue remaining
in the code that matches PCI / OF devices on ppc32) and XFree/XOrg has
to be fixed.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

From: Brett Russ <russb@emc.com>

The following code needs to be added to ide_end_drive_cmd(),
since ide_error() calls ide_end_drive_cmd() after ide_dump_status()
has left the registers pointing at the high order part of the LBA.
Using the taskfile ioctl will then lead to hobRegister[] and
subsequently hob_ports[] being loaded with the wrong values.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>

into trik.(none):/home/bzolnier/bk/ide-2.6

From: Nicholas Reilly <nreilly@magma.ca>

I have a Shuttle SN41G2 and the secondary IDE channel alternates between
IRQ 15 (correct) and IRQ 7 (causing failures accessing the DVD+-RW which is
master, no slave and also messing with the parallel port if it is enabled)
on each boot.  This is running ACPI and APIC on 2.6.5, 2.6.7 and 2.6.8. 
dmesg, dmidecode and /proc/acpi/dsdt are all identical (apart from dmesg
printing of IRQ and errors it causes) regardless of whether it decides to
go on 7 or 15.  It is now running the latest BIOS, earlier BIOS did the
same.

bart: IRQ auto-detection sometimes fails and gets "screaming" IRQ
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Patch written by Ben Woodard.  Sanity checked by Jesse Barnes.
Signed-off-by: Tony Luck <tony.luck@intel.com>

This is the third & hopefully final version of the monster cleanup
patch. It does significant cleanups of the early boot code of the
ppc64 kernel, and begins the long process of cleaning up & splitting
properly the platform support.

It completely reworks the interface between the early code that is
run in the firmware context (prom_init) and the rest of the kernel,
in such a way that will make kexec or static device-tree for embedded
people possible. The early init code can eventually be moved to a
separate link entity, it no longer touches any of the kernel globals,
everything is passed via a single blob of data in memory containing
a flattened version of the device-tree and a memory reserve map.

While doing it, I also cut the ties between pSeries and Powermac. Now,
the kernel config provides a choice between legacy iSeries and
"multiplatform". The later is a set of various supported platform,
each of them beeing a boolean switch, currently defined beeing pSeries
and PowerMac. You can enable both or just one of them. CONFIG_PPC_PSERIES
is now specifically set for IBM pSeries support, you can build a PowerMac
kernel without pSeries support if you which.
The main goal here is to simplify addition of new platform types.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

It looks like some of the places where FIB_SCAN_TOS macros were used
have lost the tos check.  This patch adds them back.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

fib_find_alias is meant to return either an exact match or the
entry just before where it should be.  Currently it returns the
entry after that.  This patch fixes that.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

>  I am trying to upgrade my labtop to 2.6.8.1. I have ArcNet COM20020
> PCMCIA card. After editing /etc/pcmcia/config to make it know about the
> module, it finds the com20020 with no problems but as soon as I try to
> start the network device the ifconfig process crashes.
:
> I fixed it by changing
> 	lp->hw.open(dev);
> to
> 	if(lp->hw.open) {
> 		lp->hw.open(dev);
> 	}
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

This patch fixes an unbalanced spin_unlock_bh in
__xfrm_find_acq_byseq left over from the larval
state SA fix.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

Stephen's patches. version change and hard_xmit printout removed.
And 2.7 is still a promise...
Signed-off-by: Robert Olsson <Robert.Olsson@data.slu.se>
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

This line in net/ipv4/Makefile was left behind when the rest of the
dumb NAT option was taken out.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

Here is a minor optimisation to fz_hash_alloc.  The break-even point
should be based on PAGE_SIZE rather than the value of divisor.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

At present, flush_cache_page() is used to handle the case where we
unmap a page or alter the page permissions on the target page with
one exception - access_process_vm().  Based upon the former, the
decision to implement this function is:

        do we need to flush the cache when we unmap or change
        the mapping permissions?

However, kernel/ptrace.c: access_process_vm() also includes into this:

        or we need to ensure cache coherency between the kernel
        and user space mapping of this page.

I argue that the use of flush_cache_page() here in the generic
code is wrong, and if an architecture wishes to use it for this
purpose, it should do so within it's architecture private
implementation of copy_to_user_page() and copy_from_user_page().

So this patch removes the flush_cache_page() from kernel/ptrace.c,
adding it to the arch-specific copy_{to,from}_user_page() where
flush_cache_page is non-empty.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into agluck-lia64.sc.intel.com:/data/home/aegl/BK/linux-ia64-release-2.6.9

It is always equal to zero.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>