Skip to content
Snippets Groups Projects
Select Git revision
  • llvm_v4.8
  • dev_smp_nullb
  • dev_smp
  • dev_nullb
  • lcd_v4.8 default
  • dev_foobar
  • dev_ixgbe
  • dev_netdummy
  • depriv
  • dev_idl_4.8_no_channels
  • dev_idl_4.8
  • dev_idl
  • temp_lcd_v4.8
  • idl_fixes
  • lcd
  • lcd_stack_protector
  • irq
  • pmfs
  • dev_nvme
  • async
  • sosp-19
  • v3.11.3
  • v3.10.14
  • v3.4.64
  • v3.0.98
  • v3.12-rc3
  • v3.11.2
  • v3.10.13
  • v3.4.63
  • v3.0.97
  • v3.12-rc2
  • v3.12-rc1
  • v3.11.1
  • v3.10.12
  • v3.4.62
  • v3.0.96
  • v3.2.51
  • v3.10.11
  • v3.4.61
  • v3.0.95
40 results
Search by author
  • Any Author
  • Abhiram Balasubramanian Abhiram Balasubramanian abhiram
  • Anton Burtsev Anton Burtsev aburtsev
  • Charlie Jacobsen Charlie Jacobsen cjacobsen
  • David Detweiler David Detweiler ddetweiler
  • David Johnson David Johnson johnsond
  • Michael Quigley Michael Quigley MichaelQuigley
  • Mike Hibler Mike Hibler hibler
  • Robert Ricci Robert Ricci ricci
  • Sarah Spall Sarah Spall spall
  • Scotty Bauer Scotty Bauer ScottyB
  • Vikram Narayanan Vikram Narayanan vikram
11 authors
  1. Jul 11, 2011
  3. Jul 05, 2011
  5. May 25, 2011
  7. May 22, 2011
  9. May 21, 2011
  11. May 20, 2011
  13. May 19, 2011
  15. May 18, 2011
  17. May 17, 2011
    • Fenghua Yu's avatar
      x86, cpu: Enable/disable Supervisor Mode Execution Protection · de5397ad
      Fenghua Yu authored 
      
Enable/disable newly documented SMEP (Supervisor Mode Execution Protection) CPU
feature in kernel. CR4.SMEP (bit 20) is 0 at power-on. If the feature is
supported by CPU (X86_FEATURE_SMEP), enable SMEP by setting CR4.SMEP. New kernel
option nosmep disables the feature even if the feature is supported by CPU.

[ hpa: moved the call to setup_smep() until after the vendor-specific
  initialization; that ensures that CPUID features are unmasked.  We
  will still run it before we have userspace (never mind uncontrolled
  userspace). ]

Signed-off-by: default avatarFenghua Yu <fenghua.yu@intel.com>
LKML-Reference: <1305157865-31727-1-git-send-email-fenghua.yu@intel.com>
Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      de5397ad
    • Rafael J. Wysocki's avatar
      PM: Allow drivers to allocate memory from .prepare() callbacks safely · 91e7c75b
      Rafael J. Wysocki authored 
      
If device drivers allocate substantial amounts of memory (above 1 MB)
in their hibernate .freeze() callbacks (or in their legacy suspend
callbcks during hibernation), the subsequent creation of hibernate
image may fail due to the lack of memory.  This is the case, because
the drivers' .freeze() callbacks are executed after the hibernate
memory preallocation has been carried out and the preallocated amount
of memory may be too small to cover the new driver allocations.
Unfortunately, the drivers' .prepare() callbacks also are executed
after the hibernate memory preallocation has completed, so they are
not suitable for allocating additional memory either.  Thus the only
way a driver can safely allocate memory during hibernation is to use
a hibernate/suspend notifier.  However, the notifiers are called
before the freezing of user space and the drivers wanting to use them
for allocating additional memory may not know how much memory needs
to be allocated at that point.

To let device drivers overcome this difficulty rework the hibernation
sequence so that the memory preallocation is carried out after the
drivers' .prepare() callbacks have been executed, so that the
.prepare() callbacks can be used for allocating additional memory
to be used by the drivers' .freeze() callbacks.  Update documentation
to match the new behavior of the code.

Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      91e7c75b
    • Rafael J. Wysocki's avatar
      PM / Hibernate: Add sysfs knob to control size of memory for drivers · ddeb6487
      Rafael J. Wysocki authored 
      Martin reports that on his system hibernation occasionally fails due
to the lack of memory, because the radeon driver apparently allocates
too much of it during the device freeze stage.  It turns out that the
amount of memory allocated by radeon during hibernation (and
presumably during system suspend too) depends on the utilization of
the GPU (e.g. hibernating while there are two KDE 4 sessions with
compositing enabled causes radeon to allocate more memory than for
one KDE 4 session).

In principle it should be possible to use image_size to make the
memory preallocation mechanism free enough memory for the radeon
driver, but in practice it is not easy to guess the right value
because of the way the preallocation code uses image_size.  For this
reason, it seems reasonable to allow users to control the amount of
memory reserved for driver allocations made after the hibernate
preallocation, which currently is constant and amounts to 1 MB.

Introduce a new sysfs file, /sys/power/reserved_size, whose value
will be used as the amount of memory to reserve for the
post-preallocation reservations made by device drivers, in bytes.
For backwards compatibility, set its default (and initial) value to
the currently used number (1 MB).

References: https://bugzilla.kernel.org/show_bug.cgi?id=34102


Reported-and-tested-by: default avatarMartin Steigerwald <Martin@Lichtvoll.de>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      ddeb6487
    • Amerigo Wang's avatar
      PM / ACPI: Remove acpi_sleep=s4_nonvs · c3b0795c
      Amerigo Wang authored 
      
acpi_sleep=s4_nonvs is superseded by acpi_sleep=nonvs, so remove it.

Signed-off-by: default avatarWANG Cong <amwang@redhat.com>
Acked-by: default avatarPavel Machek <pavel@ucw.cz>
Acked-by: default avatarLen Brown <lenb@kernel.org>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      c3b0795c
    • Jonathan Neuschäfer's avatar
      doc: timers-howto: fix a typo ("unsgined") · 04926294
      Jonathan Neuschäfer authored 
      
Signed-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      04926294
  19. May 16, 2011
  21. May 11, 2011
  23. May 10, 2011
    • Rafał Miłecki's avatar
      bcma: add Broadcom specific AMBA bus driver · 8369ae33
      Rafał Miłecki authored 
      
Broadcom has released cards based on a new AMBA-based bus type. From a
programming point of view, this new bus type differs from AMBA and does
not use AMBA common registers. It also differs enough from SSB. We
decided that a new bus driver is needed to keep the code clean.

In its current form, the driver detects devices present on the bus and
registers them in the system. It allows registering BCMA drivers for
specified bus devices and provides them basic operations. The bus driver
itself includes two important bus managing drivers: ChipCommon core
driver and PCI(c) core driver. They are early used to allow correct
initialization.

Currently code is limited to supporting buses on PCI(e) devices, however
the driver is designed to be used also on other hosts. The host
abstraction layer is implemented and already used for PCI(e).

Support for PCI(e) hosts is working and seems to be stable (access to
80211 core was tested successfully on a few devices). We can still
optimize it by using some fixed windows, but this can be done later
without affecting any external code. Windows are just ranges in MMIO
used for accessing cores on the bus.

Cc: Greg KH <greg@kroah.com>
Cc: Michael Büsch <mb@bu3sch.de>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: George Kashperko <george@znau.edu.ua>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Botting <andy@andybotting.com>
Cc: linuxdriverproject <devel@linuxdriverproject.org>
Cc: linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
Signed-off-by: default avatarRafał Miłecki <zajec5@gmail.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8369ae33
    • Joerg Roedel's avatar
      x86, gart: Rename pci-gart_64.c to amd_gart_64.c · fffcda11
      Joerg Roedel authored 
      
This file only contains code relevant for the northbridge
gart in AMD processors. This patch renames the file to
represent this fact in the filename.

Signed-off-by: default avatarJoerg Roedel <joerg.roedel@amd.com>
      fffcda11
    • Justin P. Mattock's avatar
      treewide: fix a few typos in comments · 70f23fd6
      Justin P. Mattock authored 
      
- kenrel -> kernel
- whetehr -> whether
- ttt -> tt
- sss -> ss

Signed-off-by: default avatarJustin P. Mattock <justinmattock@gmail.com>
Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      70f23fd6
  25. May 08, 2011
  27. May 06, 2011