1. 02 Oct, 2007 20 commits
  2. 01 Oct, 2007 15 commits
  3. 30 Sep, 2007 2 commits
    • Russell King's avatar
      [ARM] Resolve PCI section warnings · 46edfc54
      Russell King authored
      Fix the following (valid) section warnings:
      
      WARNING: vmlinux.o(.text+0xf7b5c): Section mismatch: reference to .init.text:pcibios_fixup_bus (between 'pci_scan_child_bus' and 'pci_scan_bridge')
      WARNING: vmlinux.o(.text+0xfc5f4): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_map_rom' and 'pci_unmap_rom')
      WARNING: vmlinux.o(.text+0xfc824): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_update_resource' and 'pci_claim_resource')
      WARNING: vmlinux.o(.text+0xfd6d8): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_setup_cardbus' and 'find_free_bus_resource')
      WARNING: vmlinux.o(.text+0xfd730): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_setup_cardbus' and 'find_free_bus_resource')
      WARNING: vmlinux.o(.text+0xfd788): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_setup_cardbus' and 'find_free_bus_resource')
      WARNING: vmlinux.o(.text+0xfd7e0): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_setup_cardbus' and 'find_free_bus_resource')
      WARNING: vmlinux.o(.text+0xfe024): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_bus_assign_resources' and 'sys_pciconfig_read')
      WARNING: vmlinux.o(.text+0xfe0f4): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_bus_assign_resources' and 'sys_pciconfig_read')
      WARNING: vmlinux.o(.text+0xfe17c): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_bus_assign_resources' and 'sys_pciconfig_read')
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      46edfc54
    • Ian Armstrong's avatar
      V4L/DVB (6052): ivtv: fix udma yuv bug · cb50f548
      Ian Armstrong authored
      Using udma yuv causes the driver becomes locked into that mode. This prevents
      use of the mpeg decoder & non-udma yuv output. This patch clears the
      operating mode when the device is closed.
      Signed-off-by: default avatarIan Armstrong <ian@iarmst.demon.co.uk>
      Signed-off-by: default avatarHans Verkuil <hverkuil@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@infradead.org>
      cb50f548
  4. 29 Sep, 2007 3 commits
    • Jan Lübbe's avatar
      fix console change race exposed by CFS · a64314e6
      Jan Lübbe authored
      The new behaviour of CFS exposes a race which occurs if a switch is
      requested when vt_mode.mode is VT_PROCESS.
      
      The process with vc->vt_pid is signaled before vc->vt_newvt is set.
      This causes the switch to fail when triggered by the monitoing process
      because the target is still -1.
      
      [ If the signal sending fails, the subsequent "reset_vc(vc)" will then
        reset vt_newvt to -1, so this works for that case too.   - Linus ]
      Signed-off-by: default avatarJan Lübbe <jluebbe@lasnet.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a64314e6
    • Linus Torvalds's avatar
      Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6 · ed7fdff5
      Linus Torvalds authored
      * 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6:
        mv643xx_eth: Check ETH_INT_CAUSE_STATE bit
      ed7fdff5
    • Nick Piggin's avatar
      i386: remove bogus comment about memory barrier · 4827bbb0
      Nick Piggin authored
      The comment being removed by this patch is incorrect and misleading.
      
      In the following situation:
      
      	1. load  ...
      	2. store 1 -> X
      	3. wmb
      	4. rmb
      	5. load  a <- Y
      	6. store ...
      
      4 will only ensure ordering of 1 with 5.
      3 will only ensure ordering of 2 with 6.
      
      Further, a CPU with strictly in-order stores will still only provide that
      2 and 6 are ordered (effectively, it is the same as a weakly ordered CPU
      with wmb after every store).
      
      In all cases, 5 may still be executed before 2 is visible to other CPUs!
      
      The additional piece of the puzzle that mb() provides is the store/load
      ordering, which fundamentally cannot be achieved with any combination of
      rmb()s and wmb()s.
      
      This can be an unexpected result if one expected any sort of global ordering
      guarantee to barriers (eg. that the barriers themselves are sequentially
      consistent with other types of barriers).  However sfence or lfence barriers
      need only provide an ordering partial ordering of memory operations -- Consider
      that wmb may be implemented as nothing more than inserting a special barrier
      entry in the store queue, or, in the case of x86, it can be a noop as the store
      queue is in order. And an rmb may be implemented as a directive to prevent
      subsequent loads only so long as their are no previous outstanding loads (while
      there could be stores still in store queues).
      
      I can actually see the occasional load/store being reordered around lfence on
      my core2. That doesn't prove my above assertions, but it does show the comment
      is wrong (unless my program is -- can send it out by request).
      
      So:
         mb() and smp_mb() always have and always will require a full mfence
         or lock prefixed instruction on x86.  And we should remove this comment.
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Cc: Paul McKenney <paulmck@us.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4827bbb0