1. 22 2月, 2014 1 次提交
  2. 21 2月, 2014 6 次提交
  3. 16 2月, 2014 6 次提交
    • R
      ACPI / dock: Associate dock platform devices with ACPI device objects · af887449
      Rafael J. Wysocki 提交于
      To allow user space to check which ACPI device object the dock
      station is represented by, make acpi_dock_add() indicate to
      platform_device_register_full() which ACPI device object should
      be the companion of the new platform device.
      
      This also ensures that the ACPI device object in question will
      not go away while the dock platform device is present (which is
      always).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      af887449
    • R
      ACPI / dock: Pass ACPI device pointer to acpi_device_is_battery() · b43109fa
      Rafael J. Wysocki 提交于
      Since we already know what the device's PNP IDs are when
      acpi_device_is_battery() is called, it is not necessary to run
      acpi_get_object_info() for the device in that function.  Instead, if
      acpi_device_is_battery() is passed a pointer to a struct acpi_device
      object, it can use the list of PNP IDs from that object, so make that
      happen and modify the function's header accordingly
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b43109fa
    • R
      ACPI / dock: Dispatch dock notifications from the global notify handler · 1e2380cd
      Rafael J. Wysocki 提交于
      The ACPI dock station code carries out an extra namespace scan
      before the main one in order to find and register all of the dock
      device objects.  Then, it registers a notify handler for each of
      them for handling dock events.
      
      However, dock device objects need not be scanned for upfront.  They
      very well can be enumerated and registered during the first phase
      of the main namespace scan, before attaching scan handlers and ACPI
      drivers to ACPI device objects.  Then, the dependent devices can be
      added to the in the second phase.  That makes it possible to drop
      the extra namespace scan, so do it.
      
      Moreover, it is not necessary to register notify handlers for all
      of the dock stations' namespace nodes, becuase notifications may
      be dispatched from the global notify handler for them.  Do that and
      drop two functions used for dock notify handling, acpi_dock_deferred_cb()
      and dock_notify_handler(), that aren't necessary any more.
      
      Finally, some dock station objects have _HID objects matching the
      ACPI container scan handler which causes it to claim those objects
      and try to handle their hotplug, but that is not a good idea,
      because those objects have their own special hotplug handling anyway.
      For this reason, the hotplug_notify flag should not be set for ACPI
      device objects representing dock stations and the container scan
      handler should be made ignore those objects, so make that happen.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1e2380cd
    • R
      Merge back earlier 'acpi-dock' material. · d6a40224
      Rafael J. Wysocki 提交于
      d6a40224
    • R
      ACPI / hotplug / PCI: Add ACPIPHP contexts to devices handled by PCIeHP · cc6254e0
      Rafael J. Wysocki 提交于
      Currently, ACPIPHP does not add hotplug context to devices that
      should be handled by the native PCI hotplug (PCIeHP) code.  The
      reason why was because PCIeHP didn't know about the devices'
      connections with ACPI and would not clean up things properly
      during an eject of an ACPI-backed device, for example.
      
      However, after recent changes that made the ACPI core create struct
      acpi_device objects for all namespace nodes regardless of the
      underlying devices' status and added PCI rescan-remove locking to
      both ACPIPHP and PCIeHP, that concern is not valid any more.
      Namely, after those changes PCIeHP need not care about the ACPI
      side of things any more and it should be serialized with respect to
      ACPIPHP and they won't be running concurrently with each other in
      any case.
      
      For this reason, make ACPIPHP to add its hotplug context to
      all devices with ACPI companions, even the ones that should be
      handled by PCIeHP in principle.  That may work around hotplug
      issues on some systems where PCIeHP is supposed to work, but it
      doesn't and the ACPI hotplug signaling works instead.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cc6254e0
    • R
      ACPI / hotplug / PCI: Rename register_slot() to acpiphp_add_context() · 3799c5a0
      Rafael J. Wysocki 提交于
      The name of register_slot() doesn't really reflect what the function
      is does, so rename it to acpiphp_add_context() and add a proper
      kerneldoc comment to it.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3799c5a0
  4. 15 2月, 2014 1 次提交
  5. 12 2月, 2014 2 次提交
    • R
      Merge back earlier 'acpi-pci-hotplug' material. · 4b49b9fe
      Rafael J. Wysocki 提交于
      Conflicts:
      	drivers/pci/hotplug/acpiphp_glue.c
      4b49b9fe
    • M
      ACPI / hotplug / PCI: Relax the checking of _STA return values · 72820594
      Mika Westerberg 提交于
      The ACPI specification (ACPI 5.0A, Section 6.3.7) says:
      
       _STA may return bit 0 clear (not present) with bit 3 set (device is
       functional). This case is used to indicate a valid device for which
       no device driver should be loaded (for example, a bridge device.)
       Children of this device may be present and valid. OSPM should
       continue enumeration below a device whose _STA returns this bit
       combination.
      
      Evidently, some BIOSes follow that and return 0x0A from _STA, which
      causes problems to happen when they trigger bus check or device check
      notifications for those devices too.  Namely, ACPIPHP thinks that they
      are gone and may drop them, for example, if such a notification is
      triggered during a resume from system suspend.
      
      To fix that, modify ACPICA to regard devies as present and
      functioning if _STA returns both the ACPI_STA_DEVICE_ENABLED
      and ACPI_STA_DEVICE_FUNCTIONING bits set for them.
      Reported-and-tested-by: NPeter Wu <lekensteyn@gmail.com>
      Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
      [rjw: Subject and changelog, minor code modifications]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      72820594
  6. 10 2月, 2014 10 次提交
  7. 09 2月, 2014 10 次提交
    • F
      Btrfs: fix data corruption when reading/updating compressed extents · a2aa75e1
      Filipe David Borba Manana 提交于
      When using a mix of compressed file extents and prealloc extents, it
      is possible to fill a page of a file with random, garbage data from
      some unrelated previous use of the page, instead of a sequence of zeroes.
      
      A simple sequence of steps to get into such case, taken from the test
      case I made for xfstests, is:
      
         _scratch_mkfs
         _scratch_mount "-o compress-force=lzo"
         $XFS_IO_PROG -f -c "pwrite -S 0x06 -b 18670 266978 18670" $SCRATCH_MNT/foobar
         $XFS_IO_PROG -c "falloc 26450 665194" $SCRATCH_MNT/foobar
         $XFS_IO_PROG -c "truncate 542872" $SCRATCH_MNT/foobar
         $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foobar
      
      This results in the following file items in the fs tree:
      
         item 4 key (257 INODE_ITEM 0) itemoff 15879 itemsize 160
             inode generation 6 transid 6 size 542872 block group 0 mode 100600
         item 5 key (257 INODE_REF 256) itemoff 15863 itemsize 16
             inode ref index 2 namelen 6 name: foobar
         item 6 key (257 EXTENT_DATA 0) itemoff 15810 itemsize 53
             extent data disk byte 0 nr 0 gen 6
             extent data offset 0 nr 24576 ram 266240
             extent compression 0
         item 7 key (257 EXTENT_DATA 24576) itemoff 15757 itemsize 53
             prealloc data disk byte 12849152 nr 241664 gen 6
             prealloc data offset 0 nr 241664
         item 8 key (257 EXTENT_DATA 266240) itemoff 15704 itemsize 53
             extent data disk byte 12845056 nr 4096 gen 6
             extent data offset 0 nr 20480 ram 20480
             extent compression 2
         item 9 key (257 EXTENT_DATA 286720) itemoff 15651 itemsize 53
             prealloc data disk byte 13090816 nr 405504 gen 6
             prealloc data offset 0 nr 258048
      
      The on disk extent at offset 266240 (which corresponds to 1 single disk block),
      contains 5 compressed chunks of file data. Each of the first 4 compress 4096
      bytes of file data, while the last one only compresses 3024 bytes of file data.
      Therefore a read into the file region [285648 ; 286720[ (length = 4096 - 3024 =
      1072 bytes) should always return zeroes (our next extent is a prealloc one).
      
      The solution here is the compression code path to zero the remaining (untouched)
      bytes of the last page it uncompressed data into, as the information about how
      much space the file data consumes in the last page is not known in the upper layer
      fs/btrfs/extent_io.c:__do_readpage(). In __do_readpage we were correctly zeroing
      the remainder of the page but only if it corresponds to the last page of the inode
      and if the inode's size is not a multiple of the page size.
      
      This would cause not only returning random data on reads, but also permanently
      storing random data when updating parts of the region that should be zeroed.
      For the example above, it means updating a single byte in the region [285648 ; 286720[
      would store that byte correctly but also store random data on disk.
      
      A test case for xfstests follows soon.
      Signed-off-by: NFilipe David Borba Manana <fdmanana@gmail.com>
      Signed-off-by: NChris Mason <clm@fb.com>
      a2aa75e1
    • J
      Btrfs: don't loop forever if we can't run because of the tree mod log · 27a377db
      Josef Bacik 提交于
      A user reported a 100% cpu hang with my new delayed ref code.  Turns out I
      forgot to increase the count check when we can't run a delayed ref because of
      the tree mod log.  If we can't run any delayed refs during this there is no
      point in continuing to look, and we need to break out.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fb.com>
      Signed-off-by: NChris Mason <clm@fb.com>
      27a377db
    • D
      btrfs: reserve no transaction units in btrfs_ioctl_set_features · 8051aa1a
      David Sterba 提交于
      Added in patch "btrfs: add ioctls to query/change feature bits online"
      modifications to superblock don't need to reserve metadata blocks when
      starting a transaction.
      Signed-off-by: NDavid Sterba <dsterba@suse.cz>
      Signed-off-by: NChris Mason <clm@fb.com>
      8051aa1a
    • J
      btrfs: commit transaction after setting label and features · d0270aca
      Jeff Mahoney 提交于
      The set_fslabel ioctl uses btrfs_end_transaction, which means it's
      possible that the change will be lost if the system crashes, same for
      the newly set features. Let's use btrfs_commit_transaction instead.
      Signed-off-by: NJeff Mahoney <jeffm@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.cz>
      Signed-off-by: NChris Mason <clm@fb.com>
      d0270aca
    • J
      Btrfs: fix assert screwup for the pending move stuff · 6cc98d90
      Josef Bacik 提交于
      Wang noticed that he was failing btrfs/030 even though me and Filipe couldn't
      reproduce.  Turns out this is because Wang didn't have CONFIG_BTRFS_ASSERT set,
      which meant that a key part of Filipe's original patch was not being built in.
      This appears to be a mess up with merging Filipe's patch as it does not exist in
      his original patch.  Fix this by changing how we make sure del_waiting_dir_move
      asserts that it did not error and take the function out of the ifdef check.
      This makes btrfs/030 pass with the assert on or off.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fb.com>
      Reviewed-by: NFilipe Manana <fdmanana@gmail.com>
      Signed-off-by: NChris Mason <clm@fb.com>
      6cc98d90
    • L
      Merge tag 'pinctrl-v3.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl · 49447903
      Linus Torvalds 提交于
      Pull pinctrl fixes from Linus Walleij:
       "First round of pin control fixes for v3.14:
      
         - Protect pinctrl_list_add() with the proper mutex.  This was
           identified by RedHat.  Caused nasty locking warnings was rootcased
           by Stanislaw Gruszka.
      
         - Avoid adding dangerous debugfs files when either half of the
           subsystem is unused: pinmux or pinconf.
      
         - Various fixes to various drivers: locking, hardware particulars, DT
           parsing, error codes"
      
      * tag 'pinctrl-v3.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
        pinctrl: tegra: return correct error type
        pinctrl: do not init debugfs entries for unimplemented functionalities
        pinctrl: protect pinctrl_list add
        pinctrl: sirf: correct the pin index of ac97_pins group
        pinctrl: imx27: fix offset calculation in imx_read_2bit
        pinctrl: vt8500: Change devicetree data parsing
        pinctrl: imx27: fix wrong offset to ICONFB
        pinctrl: at91: use locked variant of irq_set_handler
      49447903
    • L
      Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · c132adef
      Linus Torvalds 提交于
      Pull irq fix from Thomas Gleixner:
       "Add a missing Kconfig dependency"
      
      * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        genirq: Generic irq chip requires IRQ_DOMAIN
      c132adef
    • L
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · c1ff8431
      Linus Torvalds 提交于
      Pull x86 fixes from Peter Anvin:
       "Quite a varied little collection of fixes.  Most of them are
        relatively small or isolated; the biggest one is Mel Gorman's fixes
        for TLB range flushing.
      
        A couple of AMD-related fixes (including not crashing when given an
        invalid microcode image) and fix a crash when compiled with gcov"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, microcode, AMD: Unify valid container checks
        x86, hweight: Fix BUG when booting with CONFIG_GCOV_PROFILE_ALL=y
        x86/efi: Allow mapping BGRT on x86-32
        x86: Fix the initialization of physnode_map
        x86, cpu hotplug: Fix stack frame warning in check_irq_vectors_for_cpu_disable()
        x86/intel/mid: Fix X86_INTEL_MID dependencies
        arch/x86/mm/srat: Skip NUMA_NO_NODE while parsing SLIT
        mm, x86: Revisit tlb_flushall_shift tuning for page flushes except on IvyBridge
        x86: mm: change tlb_flushall_shift for IvyBridge
        x86/mm: Eliminate redundant page table walk during TLB range flushing
        x86/mm: Clean up inconsistencies when flushing TLB ranges
        mm, x86: Account for TLB flushes only when debugging
        x86/AMD/NB: Fix amd_set_subcaches() parameter type
        x86/quirks: Add workaround for AMD F16h Erratum792
        x86, doc, kconfig: Fix dud URL for Microcode data
      c1ff8431
    • L
      Merge tag 'jfs-3.14-rc2' of git://github.com/kleikamp/linux-shaggy · ec2e6cb2
      Linus Torvalds 提交于
      Pull jfs fix from David Kleikamp:
       "Fix regression"
      
      * tag 'jfs-3.14-rc2' of git://github.com/kleikamp/linux-shaggy:
        jfs: fix generic posix ACL regression
      ec2e6cb2
    • D
      jfs: fix generic posix ACL regression · c18f7b51
      Dave Kleikamp 提交于
      I missed a couple errors in reviewing the patches converting jfs
      to use the generic posix ACL function. Setting ACL's currently
      fails with -EOPNOTSUPP.
      Signed-off-by: NDave Kleikamp <dave.kleikamp@oracle.com>
      Reported-by: NMichael L. Semon <mlsemon35@gmail.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      c18f7b51
  8. 08 2月, 2014 4 次提交