1. 09 11月, 2008 4 次提交
    • K
      powerpc: Updated Freescale PPC related defconfigs · ea37194d
      Kumar Gala 提交于
      unset CONFIG_PCI_LEGACY in the defconfigs as none of them enable
      ISDN drivers which seem to be the only place we are using pci_find_device
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      ea37194d
    • L
      powerpc: Update QE/CPM2 usb_ctlr structures for USB support · 2b487065
      Li Yang 提交于
      Fixes following build error:
      
        CC      drivers/usb/gadget/fsl_qe_udc.o
      drivers/usb/gadget/fsl_qe_udc.c: In function 'qe_eprx_stall_change':
      drivers/usb/gadget/fsl_qe_udc.c:156: error: 'struct usb_ctlr' has no member named 'usb_usep'
      drivers/usb/gadget/fsl_qe_udc.c:163: error: 'struct usb_ctlr' has no member named 'usb_usep'
      drivers/usb/gadget/fsl_qe_udc.c: In function 'qe_eptx_stall_change':
      drivers/usb/gadget/fsl_qe_udc.c:173: error: 'struct usb_ctlr' has no member named 'usb_usep'
      drivers/usb/gadget/fsl_qe_udc.c:180: error: 'struct usb_ctlr' has no member named 'usb_usep'
      drivers/usb/gadget/fsl_qe_udc.c: In function 'qe_eprx_nack':
      drivers/usb/gadget/fsl_qe_udc.c:201: error: 'struct usb_ctlr' has no member named 'usb_usep'
      drivers/usb/gadget/fsl_qe_udc.c:201: error: 'struct usb_ctlr' has no member named 'usb_usep'
      drivers/usb/gadget/fsl_qe_udc.c: In function 'qe_eprx_normal':
      drivers/usb/gadget/fsl_qe_udc.c:218: error: 'struct usb_ctlr' has no member named 'usb_usep'
      drivers/usb/gadget/fsl_qe_udc.c:218: error: 'struct usb_ctlr' has no member named 'usb_usep'
      drivers/usb/gadget/fsl_qe_udc.c: In function 'qe_ep_reset':
      drivers/usb/gadget/fsl_qe_udc.c:325: error: 'struct usb_ctlr' has no member named 'usb_usep'
      drivers/usb/gadget/fsl_qe_udc.c:342: error: 'struct usb_ctlr' has no member named 'usb_usep'
      drivers/usb/gadget/fsl_qe_udc.c: In function 'qe_ep_register_init':
      drivers/usb/gadget/fsl_qe_udc.c:515: error: 'struct usb_ctlr' has no member named 'usb_usep'
      drivers/usb/gadget/fsl_qe_udc.c: In function 'ch9getstatus':
      drivers/usb/gadget/fsl_qe_udc.c:1981: error: 'struct usb_ctlr' has no member named 'usb_usep'
      make[2]: *** [drivers/usb/gadget/fsl_qe_udc.o] Error 1
      Signed-off-by: NLi Yang <leoli@freescale.com>
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      2b487065
    • M
      powerpc/86xx: Correct SOC bus-frequency in GE Fanuc SBC610 DTS · 33d2d78b
      Martyn Welch 提交于
      This patch corrects the bus-frequency value provided in the SBC610's dts.
      Signed-off-by: NMartyn Welch <martyn.welch@gefanuc.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      33d2d78b
    • K
      powerpc/fsl-booke: Fix synchronization bug w/local tlb invalidates · b41d6fee
      Kumar Gala 提交于
      The implemetation of _tlbil_pid() on Freescale Book-E cores needs
      an msync & isync after we flash invalidate the TLBs.  This was causing
      the following oops reported by Sebastian Andrzej Siewior:
      
        VFS: Mounted root (nfs filesystem) readonly.
        Freeing unused kernel memory: 148k init
        BUG: sleeping function called from invalid context at /home/bigeasy/git/linux-2.6-powerpc/mm/mmap.c:234
        in_atomic():1, irqs_disabled():0
        Call Trace:
        [df189df0] [c0007160] show_stack+0x48/0x148 (unreliable)
        [df189e30] [c0029480] __might_sleep+0xf0/0x100
        [df189e40] [c0070ac0] remove_vma+0x28/0x98
        [df189e50] [c0070c1c] exit_mmap+0xec/0x128
        [df189e80] [c002d2f4] mmput+0x54/0xec
        [df189ea0] [c0030b6c] exit_mm+0x10c/0x120
        [df189ed0] [c003288c] do_exit+0x1ac/0x6e8
        [df189f20] [c0032e48] do_group_exit+0x80/0xac
        [df189f40] [c000e9dc] ret_from_syscall+0x0/0x3c
        BUG: scheduling while atomic: udevd/956/0x10000002
        Modules linked in:
        Call Trace:
        [df189df0] [c0007160] show_stack+0x48/0x148 (unreliable)
        [df189e30] [c002ac88] __schedule_bug+0x58/0x6c
        [df189e40] [c023e6cc] schedule+0xa8/0x4a8
        [df189e90] [c002ad6c] __cond_resched+0x38/0x64
        [df189ea0] [c023ebc8] _cond_resched+0x3c/0x58
        [df189eb0] [c0030e70] put_files_struct+0x90/0xec
        [df189ed0] [c00328a8] do_exit+0x1c8/0x6e8
        [df189f20] [c0032e48] do_group_exit+0x80/0xac
        [df189f40] [c000e9dc] ret_from_syscall+0x0/0x3c
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      b41d6fee
  2. 05 11月, 2008 2 次提交
  3. 04 11月, 2008 1 次提交
  4. 02 11月, 2008 7 次提交
    • M
      sparc64: Fix PCI resource mapping on sparc64 · 5769907a
      Max Dmitrichenko 提交于
      There is a problem discovered in recent versions of ATI Mach64 driver
      in X.org on sparc64 architecture. In short, the driver fails to mmap
      MMIO aperture (PCI resource #2).
      
      I've found that kernel's __pci_mmap_make_offset() returns EINVAL. It
      checks whether user attempts to mmap more than the resource length,
      which is 0x1000 bytes in our case. But PAGE_SIZE on SPARC64 is 0x2000
      and this is what actually is being mmaped. So __pci_mmap_make_offset()
      failed for this PCI resource.
      Signed-off-by: NMax Dmitrichenko <dmitrmax@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5769907a
    • D
      sparc64: Kill annoying warning when building compat_binfmt_elf.o · a1995a65
      David S. Miller 提交于
      GCC warns because some tests against 32-bit values never evaluate to
      true due to how TASK_SIZE is defined.
      
      I always wanted to mimick powerpc's definition of TASK_SIZE, which
      is simply TASK_SIZE_OF(current) and that also fixes the warning.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a1995a65
    • A
      sparc32: kernel/trace/trace.c wants DIE_OOPS · e68f0aee
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e68f0aee
    • H
      sparc64: Fix __copy_{to,from}_user_inatomic defines. · 145e1c00
      Hugh Dickins 提交于
      Alexander Beregalov reports oops in __bzero() called from
      copy_from_user_fixup() called from iov_iter_copy_from_user_atomic(),
      when running dbench on tmpfs on sparc64: its __copy_from_user_inatomic
      and __copy_to_user_inatomic should be avoiding, not calling, the fixups.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      145e1c00
    • A
      c10555fa
    • L
      x86: Clean up late e820 resource allocation · 1f987577
      Linus Torvalds 提交于
      This makes the late e820 resources use 'insert_resource_expand_to_fit()'
      instead of doing a 'reserve_region_with_split()', and also avoids
      marking them as IORESOURCE_BUSY.
      
      This results in us being perfectly happy to use pre-existing PCI
      resources even if they were marked as being in a reserved region, while
      still avoiding any _new_ allocations in the reserved regions.  It also
      makes for a simpler and more accurate resource tree.
      
      Example resource allocation from Jonathan Corbet, who has firmware that
      has an e820 reserved entry that covered a big range (e0000000-fed003ff),
      and that had various PCI resources in it set up by firmware.
      
      With old kernels, the reserved range would force us to re-allocate all
      pre-existing PCI resources, and his reserved range would end up looking
      like this:
      
      	e0000000-fed003ff : reserved
      	  fec00000-fec00fff : IOAPIC 0
      	  fed00000-fed003ff : HPET 0
      
      where only the pre-allocated special regions (IOAPIC and HPET) were kept
      around.
      
      With 2.6.28-rc2, which uses 'reserve_region_with_split()', Jonathan's
      resource tree looked like this:
      
      	e0000000-fe7fffff : reserved
      	fe800000-fe8fffff : PCI Bus 0000:01
      	 fe800000-fe8fffff : reserved
      	fe900000-fe9d9aff : reserved
      	fe9d9b00-fe9d9bff : 0000:00:1f.3
      	 fe9d9b00-fe9d9bff : reserved
      	fe9d9c00-fe9d9fff : 0000:00:1a.7
      	 fe9d9c00-fe9d9fff : reserved
      	fe9da000-fe9dafff : 0000:00:03.3
      	 fe9da000-fe9dafff : reserved
      	fe9db000-fe9dbfff : 0000:00:19.0
      	 fe9db000-fe9dbfff : reserved
      	fe9dc000-fe9dffff : 0000:00:1b.0
      	 fe9dc000-fe9dffff : reserved
      	fe9e0000-fe9fffff : 0000:00:19.0
      	 fe9e0000-fe9fffff : reserved
      	fea00000-fea7ffff : 0000:00:02.0
      	 fea00000-fea7ffff : reserved
      	fea80000-feafffff : 0000:00:02.1
      	 fea80000-feafffff : reserved
      	feb00000-febfffff : 0000:00:02.0
      	 feb00000-febfffff : reserved
      	fec00000-fed003ff : reserved
      	 fec00000-fec00fff : IOAPIC 0
      	 fed00000-fed003ff : HPET 0
      
      and because the reserved entry had been split and moved into the
      individual resources, and because it used the IORESOURCE_BUSY flag, the
      drivers that actually wanted to _use_ those resources couldn't actually
      attach to them:
      
      	e1000e 0000:00:19.0: BAR 0: can't reserve mem region [0xfe9e0000-0xfe9fffff]
      	HDA Intel 0000:00:1b.0: BAR 0: can't reserve mem region [0xfe9dc000-0xfe9dffff]
      
      with this patch, the resource tree instead becomes
      
      	e0000000-fed003ff : reserved
      	  fe800000-fe8fffff : PCI Bus 0000:01
      	  fe9d9b00-fe9d9bff : 0000:00:1f.3
      	  fe9d9c00-fe9d9fff : 0000:00:1a.7
      	    fe9d9c00-fe9d9fff : ehci_hcd
      	  fe9da000-fe9dafff : 0000:00:03.3
      	  fe9db000-fe9dbfff : 0000:00:19.0
      	    fe9db000-fe9dbfff : e1000e
      	  fe9dc000-fe9dffff : 0000:00:1b.0
      	    fe9dc000-fe9dffff : ICH HD audio
      	  fe9e0000-fe9fffff : 0000:00:19.0
      	    fe9e0000-fe9fffff : e1000e
      	  fea00000-fea7ffff : 0000:00:02.0
      	  fea80000-feafffff : 0000:00:02.1
      	  feb00000-febfffff : 0000:00:02.0
      	  fec00000-fec00fff : IOAPIC 0
      	  fed00000-fed003ff : HPET 0
      
      ie the one reserved region now ends up surrounding all the PCI resources
      that were allocated inside of it by firmware, and because it is not
      marked BUSY, drivers have no problem attaching to the pre-allocated
      resources.
      Reported-and-tested-by: NJonathan Corbet <corbet@lwn.net>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Robert Hancock <hancockr@shaw.ca>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1f987577
    • A
      saner FASYNC handling on file close · 233e70f4
      Al Viro 提交于
      As it is, all instances of ->release() for files that have ->fasync()
      need to remember to evict file from fasync lists; forgetting that
      creates a hole and we actually have a bunch that *does* forget.
      
      So let's keep our lives simple - let __fput() check FASYNC in
      file->f_flags and call ->fasync() there if it's been set.  And lose that
      crap in ->release() instances - leaving it there is still valid, but we
      don't have to bother anymore.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      233e70f4
  5. 01 11月, 2008 2 次提交
  6. 31 10月, 2008 24 次提交