Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 15 7月, 2006 3 次提交
  3. 13 7月, 2006 4 次提交
    • D
      [SPARC]: Fix OF register translations under sub-PCI busses. · a83f9823
      由 David S. Miller 提交于 
      There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value.  For
certain kinds of things below PCI this isn't necessarily true.

Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:

    Node 0xf005f1e0
        ranges:      00000000.00000000.00000000.000001fe.01000000.00000000.01000000
                     01000000.00000000.00000000.000001fe.02000000.00000000.01000000
                     02000000.00000000.00000000.000001ff.00000000.00000001.00000000
                     03000000.00000000.00000000.000001ff.00000000.00000001.00000000
        device_type:  'pci'
        model:  'SUNW,sabre'

        Node 0xf005f9d4
            device_type:  'pci'
            model:  'SUNW,simba'

           Node 0xf0060d24
                ranges:  00000010.00000000 82010810.00000000.f0000000 01000000
			 00000014.00000000 82010814.00000000.f1000000 00800000
                name:  'ebus'

                Node 0xf0062dac
                    reg:  00000014.003083f8.00000008 --> 0x1ff.f13083f8
                    device_type:  'serial'
                    name:  'su'

So the correct translation here is:

1) Match "su" register to second ranges entry of 'ebus', which translates
   into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
   gives us "82010814.00000000.f13083f8".

2) Pass-through "SUNW,simba" since it lacks ranges property

3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
   controller node 'SUNW,sabre', and we arrive at the final physical
   MMIO address of "0x1fff13083f8".

Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.

It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work.  That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.

It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a83f9823
    • D
      [SPARC64]: Refine Sabre wsync logic. · 9bbd952e
      由 David S. Miller 提交于 
      It is only needed when there is a PCI-PCI bridge sitting
between the device and the PCI host controller which is
not a Simba APB bridge.

Add logic to handle two special cases:

1) device behind EBUS, which sits on PCI
2) PCI controller interrupts
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9bbd952e
    • D
      [SPARC64]: Fix 2 bugs in sabre_irq_build() · a23c3a86
      由 David S. Miller 提交于 
      When installing the IRQ pre-handler, we were not setting up the second
argument correctly.  It should be a pointer to the sabre_irq_data, not
the config space PIO address.

Furthermore, we only need this pre-handler installed if the device
sits behind a PCI bridge that is not Sabre or Simba/APB.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a23c3a86
    • A
      [SPARC64]: of_device_register() error checking fix · 6cc8b6f5
      由 Andrew Morton 提交于 
      device_create_file() can fail.  This causes the sparc64 compile to
fail when my fanatical __must_check patch is applied, due to -Werror.

[ Added necessary identical fix for sparc32. -DaveM]
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6cc8b6f5
  5. 11 7月, 2006 1 次提交
  7. 06 7月, 2006 2 次提交
  9. 03 7月, 2006 1 次提交
  11. 01 7月, 2006 4 次提交
  13. 30 6月, 2006 18 次提交
  15. 28 6月, 2006 2 次提交
    • K
      [PATCH] node hotplug: register cpu: remove node struct · 76b67ed9
      由 KAMEZAWA Hiroyuki 提交于 
      With Goto-san's patch, we can add new pgdat/node at runtime.  I'm now
considering node-hot-add with cpu + memory on ACPI.

I found acpi container, which describes node, could evaluate cpu before
memory. This means cpu-hot-add occurs before memory hot add.

In most part, cpu-hot-add doesn't depend on node hot add.  But register_cpu(),
which creates symbolic link from node to cpu, requires that node should be
onlined before register_cpu().  When a node is onlined, its pgdat should be
there.

This patch-set holds off creating symbolic link from node to cpu
until node is onlined.

This removes node arguments from register_cpu().

Now, register_cpu() requires 'struct node' as its argument.  But the array of
struct node is now unified in driver/base/node.c now (By Goto's node hotplug
patch).  We can get struct node in generic way.  So, this argument is not
necessary now.

This patch also guarantees add cpu under node only when node is onlined.  It
is necessary for node-hot-add vs.  cpu-hot-add patch following this.

Moreover, register_cpu calculates cpu->node_id by cpu_to_node() without regard
to its 'struct node *root' argument.  This patch removes it.

Also modify callers of register_cpu()/unregister_cpu, whose args are changed
by register-cpu-remove-node-struct patch.

[Brice.Goglin@ens-lyon.org: fix it]
Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: NBrice Goglin <Brice.Goglin@ens-lyon.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      76b67ed9
    • G
      [PATCH] 64bit resource: change pci core and arch code to use resource_size_t · e31dd6e4
      由 Greg Kroah-Hartman 提交于 
      Based on a patch series originally from Vivek Goyal <vgoyal@in.ibm.com>

Cc: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e31dd6e4
  17. 26 6月, 2006 5 次提交