1. 07 3月, 2012 3 次提交
  2. 06 3月, 2012 9 次提交
  3. 05 3月, 2012 5 次提交
    • N
      HID: hid-input: allow array fields out of range · 883e0e36
      Nikolai Kondrashov 提交于
      Allow array field values out of range as per HID 1.11 specification,
      section 6.2.25:
      
      	Rather than returning a single bit for each button in the group, an
      	array returns an index in each field that corresponds to the pressed
      	button (like keyboard scan codes). An out-of range value in and array
      	field is considered no controls asserted.
      
      Apparently, "and" above is a typo and should be "an".
      
      This fixes at least Waltop tablet pen clicks - otherwise BTN_TOUCH is never
      released.
      
      The relevant part of Waltop tablet report descriptors is this:
      
      	0x09, 0x42,         /*          Usage (Tip Switch),         */
      	0x09, 0x44,         /*          Usage (Barrel Switch),      */
      	0x09, 0x46,         /*          Usage (Tablet Pick),        */
      	0x15, 0x01,         /*          Logical Minimum (1),        */
      	0x25, 0x03,         /*          Logical Maximum (3),        */
      	0x75, 0x04,         /*          Report Size (4),            */
      	0x95, 0x01,         /*          Report Count (1),           */
      	0x80,               /*          Input,                      */
      
      This is a regression fix for commit b4b583d4 ("HID: be more strict when
      ignoring out-of-range fields").
      Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      883e0e36
    • U
      mmc: core: Fixup suspend/resume issues for UHS-I cards · e7747475
      Ulf Hansson 提交于
      Even if cards supports 1.8V I/O voltage those should anyway be
      initialized at 3.3V I/O according to (e)MMC, SD and SDIO specs.
      Some eMMC and embedded SDIO devices are able to be initialized
      at 1.8V as well, but it is better to be safe.
      
      Do note that initialization in this context means that the card
      has been completely powered off, otherwise the card will remain
      at the last I/O voltage level that were negotitiated.
      
      Due to the above being taken care of the suspend/resume issues
      for UHS-I SD-cards has been fixed.
      Signed-off-by: NUlf Hansson <ulf.hansson@stericsson.com>
      Acked-by: NPhilip Rakity <prakity@marvell.com>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Tested-by: NSubhash Jadavani <subhashj@codeaurora.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      e7747475
    • W
      mmc: mmci: reduce max_blk_count to avoid overflowing max_req_size · 8f7f6b7e
      Will Deacon 提交于
      On a system with large pages (64k in my case), the following BUG is
      triggered in MMC core:
      
      [    2.338023] BUG: failure at drivers/mmc/core/core.c:221/mmc_start_request()!
      [    2.338102] Kernel panic - not syncing: BUG!
      [    2.338155] Call trace:
      [    2.338228] [<ffffffc00008635c>] dump_backtrace+0x0/0x120
      [    2.338317] [<ffffffc0003365ec>] dump_stack+0x14/0x1c
      [    2.338403] [<ffffffc000336990>] panic+0xbc/0x1f0
      [    2.338498] [<ffffffc00027a494>] mmc_start_request+0x154/0x184
      [    2.338600] [<ffffffc00027abdc>] mmc_start_req+0x110/0x140
      [    2.338701] [<ffffffc00028604c>] mmc_blk_issue_rw_rq+0x7c/0x39c
      [    2.338804] [<ffffffc00028652c>] mmc_blk_issue_rq+0x1c0/0x468
      [    2.338905] [<ffffffc000287564>] mmc_queue_thread+0x68/0x118
      [    2.338995] [<ffffffc0000bc308>] kthread+0x84/0x8c
      
      This is because of a 64k request with a max_req_size of 64k-1 bytes.
      
      The following patch fixes the problem by limiting the max_blk_count
      such that max_blk_count * max_blk_size == max_req_size. I couldn't
      pursuade the compiler to emit a shift instead of a div without encoding
      the shift explicitly.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      8f7f6b7e
    • S
      mmc: sdhci-esdhc-imx: fix for mmc cards on i.MX5 · 5b6b0ad6
      Sascha Hauer 提交于
      On i.MX53 we have to write a special SDHCI_CMD_ABORTCMD to the
      SDHCI_TRANSFER_MODE register during a MMC_STOP_TRANSMISSION
      command. This works for SD cards. However, with MMC cards
      the MMC_SET_BLOCK_COUNT command is used instead, but this
      needs the same handling. Fix MMC cards by testing for the
      MMC_SET_BLOCK_COUNT command aswell. Tested on a custom i.MX53
      board with a Transcend MMC+ card and eMMC.
      
      The kernel started used MMC_SET_BLOCK_COUNT in 3.0, so this
      is a regression for these boards introduced in 3.0; it should
      go to 3.0/3.1/3.2-stable.
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      5b6b0ad6
    • G
      mmc: core: fix regression: set default clock gating delay to 0 · c84f15ae
      Guennadi Liakhovetski 提交于
      A recent commit "mmc: core: Use delayed work in clock gating framework"
      (597dd9d7) introduced a default 200ms delay before clock gating
      actually takes place.  This means that every time an MMC interface
      becomes idle it first stays on for 200ms before gating its clock. This
      leads to increased power consumption and is therefore a clear regression.
      This patch restores the original behaviour by setting the default delay
      to 0. Users prioritising throughput over power efficiency can still
      modify the delay via sysfs.
      Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      c84f15ae
  4. 03 3月, 2012 6 次提交
  5. 02 3月, 2012 3 次提交
  6. 01 3月, 2012 6 次提交
  7. 29 2月, 2012 8 次提交