1. 26 Feb, 2010 1 commit
  2. 07 Jan, 2010 1 commit
  3. 15 Dec, 2009 2 commits
  4. 11 Dec, 2009 1 commit
    • Johannes Berg's avatar
      firmware_class: make request_firmware_nowait more useful · 9ebfbd45
      Johannes Berg authored
      Unfortunately, one cannot hold on to the struct firmware
      that request_firmware_nowait() hands off, which is needed
      in some cases. Allow this by requiring the callback to
      free it (via release_firmware).
      Additionally, give it a gfp_t parameter -- all the current
      users call it from a GFP_KERNEL context so the GFP_ATOMIC
      isn't necessary. This also marks an API break which is
      useful in a sense, although that is obviously not the
      primary purpose of this change.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: Ming Lei <tom.leiming@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: David Woodhouse <David.Woodhouse@intel.com>
      Cc: Pavel Roskin <proski@gnu.org>
      Cc: Abhay Salunke <abhay_salunke@dell.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  5. 05 Dec, 2009 1 commit
  6. 05 Oct, 2009 1 commit
  7. 22 Sep, 2009 1 commit
    • Jan Beulich's avatar
      mm: don't use alloc_bootmem_low() where not strictly needed · 3c1596ef
      Jan Beulich authored
      Since alloc_bootmem() will never return inaccessible (via virtual
      addressing) memory anyway, using the ..._low() variant only makes sense
      when the physical address range of the allocated memory must fulfill
      further constraints, espacially since on 64-bits (or more generally in all
      cases where the pools the two variants allocate from are than the full
      available range.
      Probably the use in alloc_tce_table() could also be eliminated (based on
      code inspection of pci-calgary_64.c), but that seems too risky given I
      know nothing about that hardware and have no way to test it.
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  8. 15 Sep, 2009 1 commit
  9. 09 Sep, 2009 2 commits
    • Tejun Heo's avatar
      dmi: extend dmi_get_year() to dmi_get_date() · 3e5cd1f2
      Tejun Heo authored
      There are cases where full date information is required instead of
      just the year.  Add month and day parsing to dmi_get_year() and rename
      it to dmi_get_date().
      As the original function only required '/' followed by any number of
      parseable characters at the end of the string, keep that behavior to
      avoid upsetting existing users.
      The new function takes dates of format [mm[/dd]]/yy[yy].  Year, month
      and date are checked to be in the ranges of [1-9999], [1-12] and
      [1-31] respectively and any invalid or out-of-range component is
      returned as zero.
      The dummy implementation is updated accordingly but the return value
      is updated to indicate field not found which is consistent with how
      other dummy functions behave.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
    • Tejun Heo's avatar
      dmi: fix date handling in dmi_get_year() · 02c24fa8
      Tejun Heo authored
      Year parsing in dmi_get_year() had the following two bugs.
      * "00" is treated as invalid instead of 2000 because zero return from
        simple_strtoul() is treated as error.
      * "0N" where N >= 8 is treated as invalid of 200N because the leading
        0 is considered to specify octal.
      Fix the above two bugs by using endptr to detect invalid number and
      forcing decimal.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
  10. 17 Jun, 2009 2 commits
    • Matthew Wilcox's avatar
      [IA64] Convert ia64 to use int-ll64.h · e088a4ad
      Matthew Wilcox authored
      It is generally agreed that it would be beneficial for u64 to be an
      unsigned long long on all architectures.  ia64 (in common with several
      other 64-bit architectures) currently uses unsigned long.  Migrating
      piecemeal is too painful; this giant patch fixes all compilation warnings
      and errors that come as a result of switching to use int-ll64.h.
      Note that userspace will still see __u64 defined as unsigned long.  This
      is important as it affects C++ name mangling.
      [Updated by Tony Luck to change efi.h:efi_freemem_callback_t to use
       u64 for start/end rather than unsigned long]
      Signed-off-by: default avatarMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
    • Yinghai Lu's avatar
      firmware_map: fix hang with x86/32bit · 3b0fde0f
      Yinghai Lu authored
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13484
      Peer reported:
      | The bug is introduced from kernel 2.6.27, if E820 table reserve the memory
      | above 4G in 32bit OS(BIOS-e820: 00000000fff80000 - 0000000120000000
      | (reserved)), system will report Int 6 error and hang up. The bug is caused by
      | the following code in drivers/firmware/memmap.c, the resource_size_t is 32bit
      | variable in 32bit OS, the BUG_ON() will be invoked to result in the Int 6
      | error. I try the latest 32bit Ubuntu and Fedora distributions, all hit this
      | bug.
      |static int firmware_map_add_entry(resource_size_t start, resource_size_t end,
      |                  const char *type,
      |                  struct firmware_map_entry *entry)
      and it only happen with CONFIG_PHYS_ADDR_T_64BIT is not set.
      it turns out we need to pass u64 instead of resource_size_t for that.
      [akpm@linux-foundation.org: add comment]
      Reported-and-tested-by: default avatarPeer Chen <pchen@nvidia.com>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  11. 10 Jun, 2009 1 commit
    • Shane Huang's avatar
      [libata] ahci: Restore SB600 SATA controller 64 bit DMA · 58a09b38
      Shane Huang authored
      Community reported one SB600 SATA issue(BZ #9412), which led to 64 bit
      DMA disablement for all SB600 revisions by driver maintainers with
      commits c7a42156 and
      But the root cause is ASUS M2A-VM system BIOS bug in old revisions
      like 0901, while forcing into 32bit DMA happens to work as workaround.
      Now it's time to withdraw 4cde32fc
      so as to restore the SB600 SATA 64bit DMA capability.
      This patch is also adding the workaround for M2A-VM old BIOS revisions,
      but users are suggested to upgrade their system BIOS to the latest one
      if they meet this issue.
      Signed-off-by: default avatarShane Huang <shane.huang@amd.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
  12. 02 May, 2009 1 commit
  13. 07 Apr, 2009 1 commit
  14. 30 Mar, 2009 1 commit
    • Jean Delvare's avatar
      dmi: Let dmi_walk() users pass private data · e7a19c56
      Jean Delvare authored
      At the moment, dmi_walk() lacks flexibility, users can't pass data to
      the callback function. Add a pointer for private data to make this
      function more flexible.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Roland Dreier <rolandd@cisco.com>
  15. 18 Feb, 2009 1 commit
  16. 11 Feb, 2009 1 commit
  17. 27 Jan, 2009 1 commit
    • Rafael J. Wysocki's avatar
      DMI: Introduce dmi_first_match to make the interface more flexible · d7b1956f
      Rafael J. Wysocki authored
      Some notebooks from HP have the problem that their BIOSes attempt to
      spin down hard drives before entering ACPI system states S4 and S5.
      This leads to a yo-yo effect during system power-off shutdown and the
      last phase of hibernation when the disk is first spun down by the
      kernel and then almost immediately turned on and off by the BIOS.
      This, in turn, may result in shortening the disk's life times.
      To prevent this from happening we can blacklist the affected systems
      using DMI information.  However, only the on-board controlles should
      be blacklisted and their PCI slot numbers can be used for this
      purpose.  Unfortunately the existing interface for checking DMI
      information of the system is not very convenient for this purpose,
      because to use it, we would have to define special callback functions
      or create a separate struct dmi_system_id table for each blacklisted
      To overcome this difficulty introduce a new function
      dmi_first_match() returning a pointer to the first entry in an array
      of struct dmi_system_id elements that matches the system DMI
      information.  Then, we can use this pointer to access the entry's
      .driver_data field containing the additional information, such as
      the PCI slot number, allowing us to do the desired blacklisting.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
  18. 17 Jan, 2009 1 commit
  19. 11 Jan, 2009 1 commit
  20. 08 Jan, 2009 2 commits
  21. 06 Jan, 2009 2 commits
  22. 29 Dec, 2008 1 commit
  23. 07 Nov, 2008 1 commit
  24. 04 Nov, 2008 1 commit
    • Alok Kataria's avatar
      x86: vmware: look for DMI string in the product serial key · fd8cd7e1
      Alok Kataria authored
      Impact: Should permit VMware detection on older platforms where the
      vendor is changed.  Could theoretically cause a regression if some
      weird serial number scheme contains the string "VMware" by pure
      chance.  Seems unlikely, especially with the mixed case.
      In some user configured cases, VMware may choose not to put a VMware specific
      DMI string, but the product serial key is always there and is VMware specific.
      Add a interface to check the serial key, when checking for VMware in the DMI
      Signed-off-by: default avatarAlok N Kataria <akataria@vmware.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
  25. 31 Oct, 2008 1 commit
  26. 29 Oct, 2008 1 commit
  27. 28 Oct, 2008 1 commit
  28. 20 Oct, 2008 1 commit
    • Parag Warudkar's avatar
      x86: sysfs: kill owner field from attribute · 01e8ef11
      Parag Warudkar authored
      Tejun's commit 7b595756 made sysfs
      attribute->owner unnecessary.  But the field was left in the structure to
      ease the merge.  It's been over a year since that change and it is now
      time to start killing attribute->owner along with its users - one arch at
      a time!
      This patch is attempt #1 to get rid of attribute->owner only for
      CONFIG_X86_64 or CONFIG_X86_32 .  We will deal with other arches later on
      as and when possible - avr32 will be the next since that is something I
      can test.  Compile (make allyesconfig / make allmodconfig / custom config)
      and boot tested.
      akpm: the idea is that we put the declaration of sttribute.owner inside
      `#ifndef CONFIG_X86'.  But that proved to be too ambitious for now because
      new usages kept on turning up in subsystem trees.
      [akpm: remove the ifdef for now]
      Signed-off-by: default avatarParag Warudkar <parag.lkml@gmail.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Tejun Heo <htejun@gmail.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Roland Dreier <rolandd@cisco.com>
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  29. 16 Oct, 2008 1 commit
  30. 18 Sep, 2008 1 commit
  31. 03 Sep, 2008 1 commit
    • Mike Christie's avatar
      ibft: fix target info parsing in ibft module · bb8fb4e6
      Mike Christie authored
      I got this patch through Red Hat's bugzilla from the bug submitter and
      patch creator.  I have just fixed it up so it applies without fuzz to
      upstream kernels.
      Original patch and description from Shyam kumar Iyer:
      The issue [ibft module not displaying targets with short names] is because
      of an offset calculatation error in the iscsi_ibft.c code.  Due to this
      error directory structure for the target in /sys/firmware/ibft does not
      get created and so the initiator is unable to connect to the target.
      Note that this bug surfaced only with an name that had a short section at
      the end.  eg: "iqn.1984-05.com.dell:dell".  It did not surface when the
      iqn's had a longer section at the end.  eg:
      So, the eot_offset was calculated such that an extra 48 bytes i.e.  the
      size of the ibft_header which has already been accounted was subtracted
      This was not evident with longer iqn names because they would overshoot
      the total ibft length more than 48 bytes and thus would escape the bug.
      Signed-off-by: default avatarShyam Kumar Iyer <shyam_iyer@dell.com>
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Cc: Konrad Rzeszutek <konrad@virtualiron.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  32. 12 Aug, 2008 1 commit
  33. 30 Jul, 2008 1 commit
  34. 27 Jul, 2008 1 commit
  35. 26 Jul, 2008 1 commit