Randomize heap address like other architectures do already.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Helper function which tells us if a task is running in ESA mode.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Randomize the lower bits of the stack address like x86 and powerpc.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Shuffle code around so it looks more like x86 and powerpc.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Historically 64 bit processes use the legacy address layout. However
there is no reason why 64 bit processes shouldn't benefit from the
flexible mmap layout advantages.
Therefore just enable it.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The vdso object is currently always mapped with mm->mmap_base used as
requested address. In case of flexible mmap layout this means it gets
mapped above mmap_base and therefore potentially stealing a bit of
address space that is reserved for the stack.
In case of flexible mmap layout the object should be mapped below
mmap base. For legacy mmap layout above.
To fix this just don't request any specific address and let the mmap
code figure out an address that fits.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Reduce minimum gap between stack and mmap_base to 32MB. That way there
is a bit more space for heap and mmap for tight 31 bit address spaces.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Consider stack address randomization when calulating mmap_base for
flexible mmap layout . Because of address randomization the stack
address can be up to 8MB lower than STACK_TOP.
When calculating mmap_base this isn't taken into account, which could
lead to the case that the gap between the real stack top and mmap_base
is lower than what ulimit specifies for the maximum stack size.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
While resuming report any found paths as new to the
device drivers.
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Commit fe10ae5338 adds a memset() to clear
the structure being sent back to userspace, but accidentally used the
wrong size.
Reported-by: Brad Spengler <spender@grsecurity.net>
Signed-off-by: Kees Cook <kees.cook@canonical.com>
Cc: stable@kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
With GPIO2-fixup, another fixup for NID 0x19 was missing because the
fixup is applied only once. Add the corresponding verb to the entry.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: <stable@kernel.org>
SONY VAIO ALC275 default BIOS verb set the hardware EQ to disable.
Enable it when driver is loading.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Lenovo NB 0x9e54 use the external AMP in an inverted manner.
Set EAPD to low will enable the AMP.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Added hardware constraint in patch_hdmi.c to disable
channels 4/6 which are not supported by some older
NVIDIA GPUs.
Signed-off-by: Nitin Daga <ndaga@nvidia.com>
Acked-By: Stephen Warren <swarren@nvidia.com>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The dynamic PCM restriction based on ELD information may lead to the
problem in some cases, e.g. when the receiver is turned off. Then it
may send a TV HDMI default such as channels = 2. Since it's still
plugged, the driver doesn't know whether it's the right configuration
for future use. Now, when an app opens the device at this moment,
then turn on the receiver, the app still sends channels=2.
The right solution is to implement some kind of notification and
automatic re-open mechanism. But, this is a goal far ahead.
This patch provides a workaround for such a case by providing a new
module option static_hdmi_pcm for snd-hda-codec-hdmi module. When
this is set to true, the driver doesn't change PCM parameters per
ELD information. For users who need the static configuration like
the scenario above, set this to true.
The parameter can be changed dynamically via sysfs, too.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: <stable@kernel.org>
i.MX processors are currently manufactured by Freescale, not Motorola.
Make the manufacturer's name consistent.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
clk_get() returns a struct clk cookie to the driver and some platforms
may return NULL if they only support a single clock. clk_get() has only
failed if it returns a ERR_PTR() encoded pointer.
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Acked-by: Wan ZongShun <mcuos.com@gmail.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
clk_get() returns a struct clk cookie to the driver and some platforms
may return NULL if they only support a single clock. clk_get() has only
failed if it returns a ERR_PTR() encoded pointer.
Cc: Vincent Sanders <support@simtec.co.uk>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This switch is used to signal that user want to disable screen
transitions from portrait to landscape mode and back.
Signed-off-by: Jekyll Lai <jekyll_lai@wistron.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
A part of file: drivers/video/modedb.c was not as per the coding guidelines.
The cleanup includes:
1) Converting spcaes to tabs
2) Adding spaces on either sides of "|" operator
Signed-off-by: Mayuresh Janorkar <mayur@ti.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Swap device and driver names in serial/samsung.c
Signed-off-by: Darius Augulis <augulis.darius@gmail.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch enables interrupt generation for SDIO IRQs
of the SDHI block on the sh7377 aka G4 processor. Use
together with a recent SDHI driver using TMIO_MMC_SDIO_IRQ
and with the MMC_CAP_SDIO_IRQ flag in the board code.
The G4EVM specific SDHI platform data is also updated to
flag SDIO capabilities.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch enables interrupt generation for SDIO IRQs
of the SDHI block on the sh7367 aka G3 processor. Use
together with a recent SDHI driver using TMIO_MMC_SDIO_IRQ
and with the MMC_CAP_SDIO_IRQ flag in the board code.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch enables the interrupt generation for SDIO IRQs
of the sdhi controllers of the SoC. To make sure interrupts
are handled announce the MMC_CAP_SDIO_IRQ capability
on AP4EVB. Tested with a b43-based SDIO wireless card.
Signed-off-by: Arnd Hannemann <arnd@arndnet.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch enables interrupt generation for SDIO IRQs
of the SDHI block on the sh7366 processor. Use together
with a recent SDHI driver using TMIO_MMC_SDIO_IRQ and
with the MMC_CAP_SDIO_IRQ flag in the board code.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch enables interrupt generation for SDIO IRQs
of the SDHI block on the sh7343 processor. Use together
with a recent SDHI driver using TMIO_MMC_SDIO_IRQ and
with the MMC_CAP_SDIO_IRQ flag in the board code.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch enables runtime PM for SDHI on ecovec.
Tested with a b43 based SDIO card.
Signed-off-by: Arnd Hannemann <arnd@arndnet.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch enables the interrupt generation for SDIO IRQs
of the sdhi controllers of the SoC. To make sure SDIO IRQs
are used announce the MMC_CAP_SDIO_IRQ capability
on ap325rxa.
Signed-off-by: Arnd Hannemann <arnd@arndnet.de>
Acked-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch enables the interrupt generation for SDIO IRQs
of the sdhi controllers of the SoC. To make sure SDIO IRQs
are used, announce the MMC_CAP_SDIO_IRQ capability
on migor.
Signed-off-by: Arnd Hannemann <arnd@arndnet.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch enables the interrupt generation for SDIO IRQs
of the sdhi controllers of the SoC. To make sure interrupt
are handled announce the MMC_CAP_SDIO_IRQ capability
on ecovec, kfr2r09 and se7724.
Tested with a b43-based SDIO wireless card on ecovec.
Signed-off-by: Arnd Hannemann <arnd@arndnet.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
sysfs I/F for ACPI power devices, including AC and Battery,
has been working in upstream kenrel since 2.6.24, Sep 2007.
In 2.6.37, we made the sysfs I/F always built in and this option
disabled by default.
Now, we plan to remove this option and the ACPI power procfs
interface in 2.6.39.
First, update the feature-removal-schedule to announce this change.
Second, add runtime warnings in ACPI AC/Battery/SBS driver, so that
users will notice this change even if "make oldconfig" is used.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Update CONFIG_ACPI_PROCFS description because the processor,
video and thermal zone procfs I/F have been removed.
Some ACPI drivers, e.g. button, have their procfs I/F always built in,
because we don't have sysfs I/F replacement at the moment.
But once we finish developing the sysfs I/F for these driver,
we need CONFIG_ACPI_PROCFS to enabled/disable the corresponding procfs I/F.
So just updating the description rather than removing this option,
although there is no procfs I/F depends on it for now.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch adds event notification support to the generic
thermal sysfs framework in the kernel. The notification is in the
form of a netlink event.
Signed-off-by: R.Durgadoss <durgadoss.r@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch adds support for clock information exposed to debug-fs interface.
Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
[kgene.kim@samsung.com: removed useless empty lines]
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
I received a ppc64 bug report involving xfs but the assertion was
filtered out by the console log level. Use KERN_CRIT to ensure it
makes it out.
Signed-off-by: Anton Blanchard <anton@samba.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
In fs/xfs/xfs_trans.c::xfs_trans_unreserve_and_mod_sb() at the out:
label we have this:
ASSERT(error = 0);
I believe a comparison was intended, not an assignment. If I'm
right, the patch below fixes that up.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Alex Elder <aelder@sgi.com>
We copied ACPI's oversight of using ioremap() and creating
non-cached table mappings when we should have been using
ioremap_cache().
Signed-off-by: Len Brown <len.brown@intel.com>
MSR_IA32_ENERGY_PERF_BIAS first became available on Westmere Xeon.
It is implemented in all Sandy Bridge processors -- mobile, desktop and server.
It is expected to become increasingly important in subsequent generations.
x86_energy_perf_policy is a user-space utility to set the
hardware energy vs performance policy hint in the processor.
Most systems would benefit from "x86_energy_perf_policy normal"
at system startup, as the hardware default is maximum performance
at the expense of energy efficiency.
See x86_energy_perf_policy.8 man page for more information.
Background:
Linux-2.6.36 added "epb" to /proc/cpuinfo to indicate
if an x86 processor supports MSR_IA32_ENERGY_PERF_BIAS,
without actually modifying the MSR.
In March, 2010, Venkatesh Pallipadi proposed a small driver
that programmed MSR_IA32_ENERGY_PERF_BIAS, based on
the cpufreq governor in use. It also offered
a boot-time cmdline option to override.
http://lkml.org/lkml/2010/3/4/457
But hiding the hardware policy behind the
governor choice was deemed "kinda icky".
In June, 2010, I proposed a generic user/kernel API to
generalize the power/performance policy trade-off.
"RFC: /sys/power/policy_preference"
http://lkml.org/lkml/2010/6/16/399
That is my preference for implementing this capability,
but I received no support on the list.
So in September, 2010, I sent x86_energy_perf_policy.c to LKML,
a user-space utility that scribbles directly to the MSR.
http://lkml.org/lkml/2010/9/28/246
Here is that same utility, after responding to some review feedback,
to live in tools/power/, where it is easily found.
Signed-off-by: Len Brown <len.brown@intel.com>
