1. 19 3月, 2013 9 次提交
  2. 16 3月, 2013 12 次提交
  3. 10 3月, 2013 1 次提交
    • L
      Atmel MXT touchscreen: increase reset timeouts · 8343bce1
      Linus Torvalds 提交于
      There is a more complete atmel patch-series out by Nick Dyer that fixes
      this and other things, but in the meantime this is the minimal thing to
      get the touchscreen going on (at least my) Pixel Chromebook.
      
      Not that I want my dirty fingers near that beautiful screen, but it
      seems that a non-initialized touchscreen will also end up being a
      constant wakeup source, so you have to disable it to go to sleep.  And
      it's easier to just fix the initialization sequence.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8343bce1
  4. 09 3月, 2013 3 次提交
  5. 08 3月, 2013 8 次提交
  6. 07 3月, 2013 4 次提交
  7. 06 3月, 2013 3 次提交
    • M
      efivarfs: return accurate error code in efivarfs_fill_super() · feff5dc4
      Matt Fleming 提交于
      Joseph was hitting a failure case when mounting efivarfs which
      resulted in an incorrect error message,
      
        $ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory
      
      triggered when efivarfs_valid_name() returned -EINVAL.
      
      Make sure we pass accurate return values up the stack if
      efivarfs_fill_super() fails to build inodes for EFI variables.
      Reported-by: NJoseph Yasi <joe.yasi@gmail.com>
      Reported-by: NLingzhu Xiang <lxiang@redhat.com>
      Cc: Josh Boyer <jwboyer@redhat.com>
      Cc: Jeremy Kerr <jk@ozlabs.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: <stable@vger.kernel.org> # v3.8
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      feff5dc4
    • M
      efivars: efivarfs_valid_name() should handle pstore syntax · 123abd76
      Matt Fleming 提交于
      Stricter validation was introduced with commit da27a243
      ("efivarfs: guid part of filenames are case-insensitive") and commit
      47f531e8 ("efivarfs: Validate filenames much more aggressively"),
      which is necessary for the guid portion of efivarfs filenames, but we
      don't need to be so strict with the first part, the variable name. The
      UEFI specification doesn't impose any constraints on variable names
      other than they be a NULL-terminated string.
      
      The above commits caused a regression that resulted in users seeing
      the following message,
      
        $ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory
      
      whenever pstore EFI variables were present in the variable store,
      since their variable names failed to pass the following check,
      
          /* GUID should be right after the first '-' */
          if (s - 1 != strchr(str, '-'))
      
      as a typical pstore filename is of the form, dump-type0-10-1-<guid>.
      The fix is trivial since the guid portion of the filename is GUID_LEN
      bytes, we can use (len - GUID_LEN) to ensure the '-' character is
      where we expect it to be.
      
      (The bogus ENOMEM error value will be fixed in a separate patch.)
      Reported-by: NJoseph Yasi <joe.yasi@gmail.com>
      Tested-by: NJoseph Yasi <joe.yasi@gmail.com>
      Reported-by: NLingzhu Xiang <lxiang@redhat.com>
      Cc: Josh Boyer <jwboyer@redhat.com>
      Cc: Jeremy Kerr <jk@ozlabs.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: <stable@vger.kernel.org> # v3.8
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      123abd76
    • M
      efi: be more paranoid about available space when creating variables · 68d92986
      Matthew Garrett 提交于
      UEFI variables are typically stored in flash. For various reasons, avaiable
      space is typically not reclaimed immediately upon the deletion of a
      variable - instead, the system will garbage collect during initialisation
      after a reboot.
      
      Some systems appear to handle this garbage collection extremely poorly,
      failing if more than 50% of the system flash is in use. This can result in
      the machine refusing to boot. The safest thing to do for the moment is to
      forbid writes if they'd end up using more than half of the storage space.
      We can make this more finegrained later if we come up with a method for
      identifying the broken machines.
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      Cc: Josh Boyer <jwboyer@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      68d92986