1. 18 9月, 2006 1 次提交
  2. 08 9月, 2006 1 次提交
  3. 27 8月, 2006 2 次提交
  4. 28 7月, 2006 1 次提交
  5. 22 7月, 2006 8 次提交
  6. 13 7月, 2006 2 次提交
    • 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
    • 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
  7. 11 7月, 2006 1 次提交
  8. 03 7月, 2006 1 次提交
  9. 01 7月, 2006 2 次提交
  10. 30 6月, 2006 7 次提交
  11. 28 6月, 2006 3 次提交
  12. 26 6月, 2006 4 次提交
  13. 24 6月, 2006 4 次提交
  14. 23 6月, 2006 1 次提交
  15. 20 6月, 2006 2 次提交
    • D
      [SPARC]: Kill __irq_itoa(). · c6387a48
      David S. Miller 提交于
      This ugly hack was long overdue to die.
      
      It was a way to print out Sparc interrupts in a more freindly format,
      since IRQ numbers were arbitrary opaque 32-bit integers which vectored
      into PIL levels.  These 32-bit integers were not necessarily in the
      0-->NR_IRQS range, but the PILs they vectored to were.
      
      The idea now is that we will increase NR_IRQS a little bit and use a
      virtual<-->real IRQ number mapping scheme similar to PowerPC.
      
      That makes this IRQ printing hack irrelevant, and furthermore only a
      handful of drivers actually used __irq_itoa() making it even less
      useful.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c6387a48
    • B
      [SPARC]: Fix iommu_flush_iotlb end address · 3185d4d2
      Bob Breuer 提交于
      Fix the calculation of the end address when flushing iotlb entries to
      ram.  This bug has been a cause of esp dma errors, and it affects
      HyperSPARC systems much worse than SuperSPARC systems.
      Signed-off-by: NBob Breuer <breuerr@mc.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3185d4d2