This helps deal with the invisible bridge that sits between
the host controller and the top-most visisble PCI devices
on hypervisor systems.

For example, on T1000 the bus-range property says 2 --> 4
and so there is a PCI express bridge at bus 2, devfn 0, etc.

So if we don't force the dummy host controller to bus zero,
we'll try to create two devices with the same domain/bus/devfn
triplet.

Also, add some more log diagnostics to make debugging stuff like this
easyer.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We fake up a dummy one in all cases because that is the simplest
thing to do and it happens to be necessary for hypervisor systems.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Based upon a similar patch for x86_64 written by
Stephen Hemminger.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Set but never used.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We don't do the "Simba APB is a PBM" bogosity for Sabre
controllers any longer, so this pbms_same_domain thing
is no longer necessary.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Implemented but never actually used.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

All the implementations can be identical and generic, so
no need for controller specific methods.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It is only used in one spot and we can just fetch the
OF property right there.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Set but never used.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It can be done for every PCI configuration using OF properties.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The SIMBA APB bridge is strange, it is a PCI bridge but it lacks
some standard OF properties, in particular it lacks a 'ranges'
property.

What you have to do is read the IO and MEM range registers in
the APB bridge to determine the ranges handled by each bridge.
So fill in the bus resources by doing that.

Since we now handle this quirk in the generic PCI and OF device
probing layers, we can flat out eliminate all of that code from
the sabre pci controller driver.

In fact we can thus eliminate completely another quirk of the sabre
driver.  It tried to make the two APB bridges look like PBMs but that
makes zero sense now (and it's questionable whether it ever made sense).
So now just use pbm_A and probe the whole PCI hierarchy using that as
the root.

This simplification allows many future cleanups to occur.

Also, I've found yet another quirk that needs to be worked around
while testing this.  You can't use the 'class-code' OF firmware
property, especially for IDE controllers.  We have to read the value
out of PCI config space or else we'll see the value the device was
showing before it was programmed into native mode.

I'm starting to think it might be wise to just read all of the values
out of PCI config space instead of using the OF properties. :-/
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Need to traverse recursively down child busses else we only
get the file created under devices at the top-level.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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

The only user was bus_dvma_to_mem() which is no longer used
by any driver, so kill that, and the export of pci_memspace_mask.

The only user now is the PCI mmap support code.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Almost entirely taken from the 64-bit PowerPC PCI code.

This allowed to eliminate a ton of cruft from the sparc64
PCI layer.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Also, do not try to compute resources by hand, instead use
the pre-computed ones in the of_device.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Also, we don't need to store or use the PBM so kill that
from the linux_ebus.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This allows us to simplify sharing code with powerpc which
has properties that have various forms of capitalization
when on the sparc64 side the property is all lower-case.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Finally, we actually change the functions themselves.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

- Removes days_in_mo[], as it's almost identical to month_days[]
- Use the leapyear() macro
- Line length wrapping.
Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It should return an error code not a boolean.

Based upon an hpet timer fix by Thomas Gleixner.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

I'd like to thank John Stul and others for helping
me along the way.

A lot of cleanups fell out of this.  For example, the get_compare()
tick_op was totally unused, so was deleted.  And the most often used
tick_op members were grouped together for cache-friendlyness.

The sparc64 TSC is given to the kernel as a one-shot timer.

tick_ops->init_timer() simply turns off the privileged bit in
the tick register (when possible), and disables the interrupt
by setting bit 63 in the compare register.  The ->disable_irq()
op also sets this bit.

tick_ops->add_compare() is changed to:

1) Add the given delta to "tick" not to "compare"
2) Return a boolean which, if true, means that the tick
   value read after writing the compare value was found
   to have incremented past the initial tick value.  This
   mirrors logic used in the HPET driver's ->next_event()
   method.

Each tick_ops implementation also now provides a name string.
And we feed this into the clocksource and clockevents layers.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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

Things were scattered all over the place, split between
SMP and non-SMP.

Unify it all so that dyntick support is easier to add.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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

While building a test kernel for the new esp driver (against
git-current), I hit this bug. Trivial fix, put the inline declaration
in the right place. :)
Signed-off-by: NTom "spot" Callaway <tcallawa@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Do not sign extend args using the sys32_ipc stub, that is
buggy and unnecessary.

Based upon an excellent report by Mikael Pettersson.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix section mismatch in arch/sparc/kernel/pcic.c and 
arch/sparc64/kernel/pci.c.
Signed-off-by: NRobert Reif <reif@earthlink.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

I don't figure anyone really cares about SunOS syscall emulation, and I
certainly don't.  But I'm getting rid of uses of the OPEN_MAX and CHILD_MAX
compile-time constant, and these are almost the only ones.  OPEN_MAX is a
bogus constant with no meaning about anything.  The RLIMIT_NOFILE resource
limit is what sysconf (_SC_OPEN_MAX) actually wants to return.

The CHILD_MAX cases weren't actually using anything I want to get rid of,
but I noticed that they are there and are wrong too.  The CHILD_MAX value
is not really unlimited as a -1 return from sysconf indicates.  The
RLIMIT_NPROC resource limit is what sysconf (_SC_CHILD_MAX) wants to return.
Signed-off-by: NRoland McGrath <roland@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are several IOMMU allocator bugs.  Instead of trying to fix this
overly complicated code, just mirror the PCI IOMMU arena allocator
which is very stable and well stress tested.

I tried to make the code as identical as possible so we can switch
sun4u PCI and SBUS over to a common piece of IOMMU code.  All that
will be need are two callbacks, one to do a full IOMMU flush and one
to do a streaming buffer flush.

This patch gets rid of a lot of hangs and mysterious crashes on SBUS
sparc64 systems, at least for me.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The manual says that it is required and we actually have crash reports
where loads see stale data due to not having membars here.

In one case the networking does:

	memset(skb, 0, offsetof(struct sk_buff, truesize));

and then some code later checks skb->nohdr for zero, but it's still
the value that was there before the memset().

Note that arch/sparc64/lib/xor.S already got this right.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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

We have to make sure to use base-pagesize TLB entries even during the
early transition period where we need TLB miss handling but don't have
the kernel page tables setup yet for the linear region.

Also, it is necessary therefore to not use the 4MB TSB for these
translations, and instead use the normal kernel TSB.  This allows us
to also get rid of the 4MB tsb for debug builds which shrinks the
kernel a little bit.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

These pte loops all assume the passed in address is HPAGE
aligned, make sure that is actually true.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

sys_mbind
sys_get_mempolicy
sys_set_mempolicy
sys_kexec_load
sys_move_pages
sys_getcpu
sys_epoll_pwait

This work is largely a result of David Woodhouse's most
excellent missing syscalls patch.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix atomicity of TIF update in flush_thread() for sparc64

Fixes correctly the race by using *_ti_thread_flag.

Race :

parent process executing :
sys_ptrace()
 (lock_kernel())
 (ptrace_get_task_struct(pid))
 arch_ptrace()
   ptrace_detach()
     ptrace_disable(child);
       clear_singlestep(child);
         clear_tsk_thread_flag(child, TIF_SINGLESTEP);
         (which clears the TIF_SINGLESTEP flag atomically from a different
          process)
 (put_task_struct(child))
 (unlock_kernel())

And at the same time, in the child process :
sys_execve()
 do_execve()
   search_binary_handler()
     load_elf_binary()
       flush_old_exec()
         flush_thread()
           doing a non-atomic thread flag update
Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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

Just leave them as zero if we couldn't calculate it.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We mistakedly modify 'bus' in the innermost loop.  What
should happen is that at each register index iteration,
we start with the same 'bus'.

So preserve it's value at the top level, and use a loop
local variable 'dbus' for iteration.

This bug causes registers other than the first to be
decoded improperly.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>