1. 01 12月, 2010 2 次提交
  2. 23 11月, 2010 1 次提交
  3. 19 11月, 2010 1 次提交
  4. 16 11月, 2010 1 次提交
  5. 15 11月, 2010 1 次提交
  6. 11 11月, 2010 3 次提交
  7. 05 11月, 2010 1 次提交
    • B
      Input: atkbd - add 'terminal' parameter for IBM Terminal keyboards · 8c5188b6
      Benjamin LaHaise 提交于
      Many of the IBM Terminal keyboards from the 1980s and early 1990s communicate
      using a protocol similar, but not identical to the AT keyboard protocol.
      (Models known to be like this include 6110344, 6110668, 1390876, 1386887, and
      possibly others.)
      
      When the connector is rewired or adapter to an AT-DIN or PS/2 connector, they
      can be connected to a standard PC, with three caveats:
      
      a) They can only use scancode set 3; requests to use anything else are
      quietly ignored.
      b) The AT Command to request Make, Break and Repeat codes is not properly
      interpreted.
      c) The top function keys on a 122 key keyboard, and the arrow/edit keys in
      the middle of the board send non-standard scancodes.
      
      C) is easily taken care of in userspace, by use of setkeycodes
      B) can be taken care of by a userspace hack (that makes the kernel complain
      in dmesg)
      A) is fixable in theory, but on the keyboard i tested on (6110668), it seems
      to be detected unoverridably as Set 2, causing userspace oddities that make
      it harder to fix C).
      
      Enclosed is a small patch to the kernel that fixes A) and B) in the kernel,
      making it much easier to fix C) in userspace. It adds a single kernel
      command line parameter that overrides the detection that sets these boards
      as set 2, and instead of sending the Make-break-repeat command to the
      keyboard, it sends the make-break command, which is properly recognized by
      these keyboards. Software level key repeating seems to make up for the lack
      of hardware repeat codes perfectly.
      
      Without manually setting the command line parameter (tentatively named
      atkbd.terminal), this code has no effect, and the driver works exactly as
      before.
      
      See also:
      
      http://www.seasip.info/VintagePC/ibm_1390876.html
      http://www.seasip.info/VintagePC/ibm_6110344.html
      http://geekhack.org/showwiki.php?title=Island:7306Signed-off-by: NErika Quinn <erikas.aubade@gmail.com>
      Signed-off-by: NBenjamin LaHaise <bcrl@kvack.org>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      8c5188b6
  8. 04 11月, 2010 4 次提交
  9. 01 11月, 2010 5 次提交
  10. 31 10月, 2010 10 次提交
  11. 30 10月, 2010 11 次提交
    • T
      audit: Call tty_audit_push_task() outside preempt disabled · 3c80fe4a
      Thomas Gleixner 提交于
      While auditing all tasklist_lock read_lock sites I stumbled over the
      following call chain:
      
      audit_prepare_user_tty()
        read_lock(&tasklist_lock);
        tty_audit_push_task();
           mutex_lock(&buf->mutex);
      
           --> buf->mutex is locked with preemption disabled.
      
      Solve this by acquiring a reference to the task struct under
      rcu_read_lock and call tty_audit_push_task outside of the preempt
      disabled region.
      
      Move all code which needs to be protected by sighand lock into
      tty_audit_push_task() and use lock/unlock_sighand as we do not hold
      tasklist_lock.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      3c80fe4a
    • A
      mtd: fix build error in m25p80.c · 40847437
      Andres Salomon 提交于
      While building an x86 distro kernel, I hit the following:
      
      Kernel: arch/x86/boot/bzImage is ready  (#7)
      ERROR: "of_mtd_parse_partitions" [drivers/mtd/devices/m25p80.ko]
      undefined!
      
      of_mtd_parse_partitions is defined with MTD_OF_PARTS, and that's only
      built on PPC and microblaze.  The code in question should be wrapped w/
      a stricter #ifdef.
      Signed-off-by: NAndres Salomon <dilinger@queued.net>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      40847437
    • D
      mtd: Remove redundant mutex from mtd_blkdevs.c · 8cc9de3e
      David Woodhouse 提交于
      In commit 2a48fc0a ('block: autoconvert
      trivial BKL users to private mutex'), Arnd replaced the BKL usage with a
      mutex. However, Maxim has already provided a better fix in commit
      480792b7 ('mtd: blktrans: kill BKL'),
      which was simply to remove the BKL without replacing it — since he'd
      already made it do all necessary locking for itself.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      8cc9de3e
    • F
      MTD: Fix wrong check register_blkdev return value · 6fe4c590
      Frank Li 提交于
      register_blkdev return 1..255 when major = 0.
      
      if (ret ) {
      	printk(KERN_WARNING "Unable to register %s block device on major %d: %d\n",
      		tr->name, tr->major, ret);
      	      mutex_unlock(&mtd_table_mutex);
      	return ret;
      }
      
      Above code will return fail when register_blkdev return allocated major number.
      Signed-off-by: NFrank Li <Frank.Li@freescale.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      6fe4c590
    • T
      staging: Final semaphore cleanup · 45f4d024
      Thomas Gleixner 提交于
      Fixup the last remaining users of DECLARE_MUTEX and init_MUTEX.
      
      Scripted conversion, resulting code is binary equivalent.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      LKML-Reference: <20100907125057.278833764@linutronix.de>
      45f4d024
    • R
      i2c-intel-mid: Driver depends on PCI · 9cc11dee
      Randy Dunlap 提交于
      i2c-intel-mid driver uses PCI data structs and interfaces,
      so it should depend on PCI.  Fixes these build errors:
      
      drivers/i2c/busses/i2c-intel-mid.c:977: error: implicit declaration of function 'pci_request_region'
      drivers/i2c/busses/i2c-intel-mid.c:1077: error: implicit declaration of function 'pci_release_region'
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Ba Zheng <zheng.ba@intel.com>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: linux-i2c@vger.kernel.org
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      9cc11dee
    • V
      drivers/dma/Kconfig: add part number for Topcliff. · d2df4085
      Valdis.Kletnieks@vt.edu 提交于
      Product codenames are OK, but once an actual product name is available,
      it should be referenced as well.
      
        http://ark.intel.com/chipset.aspx?familyID=52499Signed-off-by: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d2df4085
    • C
      phy/marvell: rename 88ec048 to 88e1318s and fix mscr1 addr · 337ac9d5
      Cyril Chemparathy 提交于
      The marvell 88ec048's official part number is 88e1318s.  This patch renames
      definitions in the driver to reflect this.
      
      In addition, a minor bug fix has been added to write back the MSCR1 register
      value properly.
      Signed-off-by: NCyril Chemparathy <cyril@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      337ac9d5
    • G
      Staging: dream: remove dream driver and arch from tree · 3414df8c
      Greg Kroah-Hartman 提交于
      This code is stalled, with no one working on it anymore, and the main
      msm code is now going through the proper channels to get merged
      correctly.
      
      So remove it as it contains a number of kernel information leaks and it
      is doubtful if it even still builds anymore.
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Acked-by: NBryan Huntsman <bryanh@codeaurora.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3414df8c
    • L
      b43: Fix warning at drivers/mmc/core/core.c:237 in mmc_wait_for_cmd · 9f2a0fac
      Larry Finger 提交于
      On module removal, the sdio version of b43 generates the following warning:
      
      [  851.560519] ------------[ cut here ]------------
      [  851.560531] WARNING: at drivers/mmc/core/core.c:237 mmc_wait_for_cmd+0x88/0x90()
      [  851.560534] Hardware name: 20552PG
      [  851.560536] Modules linked in: b43(-) ssb mmc_block binfmt_misc rfcomm sco bnep ppdev l2cap ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp kvm_intel kvm arc4 iwlagn snd_hda_codec_conexant snd_hda_intel snd_hda_codec iwlcore snd_hwdep snd_pcm thinkpad_acpi mac80211 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq r852 joydev snd_timer sm_common pcmcia nand snd_seq_device cfg80211 sdhci_pci btusb psmouse tpm_tis yenta_socket nand_ids lp snd pcmcia_rsrc nand_ecc bluetooth sdhci tpm pcmcia_core parport mtd snd_page_alloc serio_raw tpm_bios soundcore nvram led_class sha256_generic aes_i586 aes_generic dm_crypt i915 drm_kms_helper drm ahci intel_agp i2c_algo_bit intel_gtt e1000e libahci video agpgart output
      [  851.560620] Pid: 2504, comm: rmmod Not tainted 2.6.36-titan0+ #1
      [  851.560622] Call Trace:
      [  851.560631]  [<c014a102>] warn_slowpath_common+0x72/0xa0
      [  851.560636]  [<c04d94c8>] ? mmc_wait_for_cmd+0x88/0x90
      [  851.560641]  [<c04d94c8>] ? mmc_wait_for_cmd+0x88/0x90
      [  851.560645]  [<c014a152>] warn_slowpath_null+0x22/0x30
      [  851.560649]  [<c04d94c8>] mmc_wait_for_cmd+0x88/0x90
      [  851.560655]  [<c0401585>] ? device_release+0x25/0x80
      [  851.560660]  [<c04df210>] mmc_io_rw_direct_host+0xa0/0x150
      [  851.560665]  [<c04df370>] mmc_io_rw_direct+0x30/0x40
      [  851.560669]  [<c04e06e7>] sdio_disable_func+0x37/0xa0
      [  851.560683]  [<f8dfcb80>] b43_sdio_remove+0x30/0x50 [b43]
      [  851.560687]  [<c04df8cc>] sdio_bus_remove+0x1c/0x60
      [  851.560692]  [<c016d39f>] ? blocking_notifier_call_chain+0x1f/0x30
      [  851.560697]  [<c0404991>] __device_release_driver+0x51/0xb0
      [  851.560701]  [<c0404a7f>] driver_detach+0x8f/0xa0
      [  851.560705]  [<c0403c83>] bus_remove_driver+0x63/0xa0
      [  851.560709]  [<c0405039>] driver_unregister+0x49/0x80
      [  851.560713]  [<c0405039>] ? driver_unregister+0x49/0x80
      [  851.560718]  [<c04dfad7>] sdio_unregister_driver+0x17/0x20
      [  851.560727]  [<f8dfcb42>] b43_sdio_exit+0x12/0x20 [b43]
      [  851.560734]  [<f8dfe76f>] b43_exit+0x17/0x3c [b43]
      [  851.560740]  [<c017fb8d>] sys_delete_module+0x13d/0x200
      [  851.560747]  [<c01fd7d2>] ? do_munmap+0x212/0x300
      [  851.560752]  [<c010311f>] sysenter_do_call+0x12/0x28
      [  851.560757] ---[ end trace 31e14488072d2f7d ]---
      [  851.560759] ------------[ cut here ]------------
      
      The warning is caused by b43 not claiming the device before calling
      sdio_disable_func().
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Reported-by: NArnd Hannemann <arnd@arndnet.de>
      Tested-by: NArnd Hannemann <arnd@arndnet.de>
      Cc: Stable <stable@kernel.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9f2a0fac
    • P
      libertas: Fix sd8686 firmware reload · 731b2034
      Paul Fox 提交于
      For the SD8686, we cannot rely on the scratch register to read the firmware
      load status, because the same register is used for storing RX packet length.
      Broaden the check to account for this.
      
      The module can now be unloaded/reloaded successfully.
      
      Based on the implementation from libertas_tf.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Acked-by: NDan Williams <dcbw@redhat.com>
      Signed-off-by: NSteve deRosier <steve@cozybit.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      731b2034