Seiji Aguchi [Wed, 14 Nov 2012 20:28:18 +0000 (20:28 +0000)]
efi_pstore: Add a sequence counter to a variable name
[Issue]
Currently, a variable name, which identifies each entry, consists of type, id and ctime.
But if multiple events happens in a short time, a second/third event may fail to log because
efi_pstore can't distinguish each event with current variable name.
[Solution]
A reasonable way to identify all events precisely is introducing a sequence counter to
the variable name.
The sequence counter has already supported in a pstore layer with "oopscount".
So, this patch adds it to a variable name.
Also, it is passed to read/erase callbacks of platform drivers in accordance with
the modification of the variable name.
<before applying this patch>
a variable name of first event: dump-type0-1-12345678
a variable name of second event: dump-type0-1-12345678
In case of a write callback executed in pstore_console_write(), "0" is added to
an argument of the write callback because it just logs all kernel messages and
doesn't need to care about multiple events.
Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
Seiji Aguchi [Wed, 14 Nov 2012 20:27:28 +0000 (20:27 +0000)]
efi_pstore: Add ctime to argument of erase callback
[Issue]
Currently, a variable name, which is used to identify each log entry, consists of type,
id and ctime. But an erase callback does not use ctime.
If efi_pstore supported just one log, type and id were enough.
However, in case of supporting multiple logs, it doesn't work because
it can't distinguish each entry without ctime at erasing time.
<Example>
As you can see below, efi_pstore can't differentiate first event from second one without ctime.
a variable name of first event: dump-type0-1-12345678
a variable name of second event: dump-type0-1-23456789
This patch adds ctime to an argument of an erase callback.
It works across reboots because ctime of pstore means the date that the record was originally stored.
To do this, efi_pstore saves the ctime to variable name at writing time and passes it to pstore
at reading time.
Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
Seiji Aguchi [Wed, 14 Nov 2012 20:26:46 +0000 (20:26 +0000)]
efi_pstore: Remove a logic erasing entries from a write callback to hold multiple logs
[Issue]
Currently, efi_pstore driver simply overwrites existing panic messages in NVRAM.
So, in the following scenario, we will lose 1st panic messages.
1. kernel panics.
2. efi_pstore is kicked and writes panic messages to NVRAM.
3. system reboots.
4. kernel panics again before a user checks the 1st panic messages in NVRAM.
[Solution]
A reasonable solution to fix the issue is just holding multiple logs without erasing
existing entries.
This patch removes a logic erasing existing entries in a write callback
because the logic is not needed in the write callback to support holding multiple logs.
Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
Seiji Aguchi [Wed, 14 Nov 2012 20:26:21 +0000 (20:26 +0000)]
efi_pstore: Add a logic erasing entries to an erase callback
[Issue]
Currently, efi_pstore driver simply overwrites existing panic messages in NVRAM.
So, in the following scenario, we will lose 1st panic messages.
1. kernel panics.
2. efi_pstore is kicked and writes panic messages to NVRAM.
3. system reboots.
4. kernel panics again before a user checks the 1st panic messages in NVRAM.
[Solution]
A reasonable solution to fix the issue is just holding multiple logs without erasing
existing entries.
This patch freshly adds a logic erasing existing entries, which shared with a write callback,
to an erase callback.
To support holding multiple logs, the write callback doesn't need to erase any entries and
it will be removed in a subsequent patch.
Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
Seiji Aguchi [Wed, 14 Nov 2012 20:25:37 +0000 (20:25 +0000)]
efi_pstore: Check remaining space with QueryVariableInfo() before writing data
[Issue]
As discussed in a thread below, Running out of space in EFI isn't a well-tested scenario.
And we wouldn't expect all firmware to handle it gracefully.
http://marc.info/?l=linux-kernel&m=134305325801789&w=2
On the other hand, current efi_pstore doesn't check a remaining space of storage at writing time.
Therefore, efi_pstore may not work if it tries to write a large amount of data.
[Patch Description]
To avoid handling the situation above, this patch checks if there is a space enough to log with
QueryVariableInfo() before writing data.
Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
Linus Torvalds [Wed, 14 Nov 2012 21:46:40 +0000 (13:46 -0800)]
Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux
Pull power tools fixes from Len Brown:
"A pair of power tools patches -- a 3.7 regression fix plus a bug fix."
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux:
tools/power turbostat: graceful fail on garbage input
tools/power turbostat: Repair Segmentation fault when using -i option
Linus Torvalds [Wed, 14 Nov 2012 21:45:23 +0000 (13:45 -0800)]
Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus
Pull MIPS update from Ralf Baechle:
"To avoid unnecessary risk and work the preemption fixes are combined
with some preparatory work that isn't strictly required. So it's
really just 3 fixes:
- Get is_compat_task() to do the right thing while simplifying it.
The unnecessary complexity hid a rarely striking bug which could be
triggered by ext3/ext4 under certain circumstances.
- Resolve a preemption issue in the irqflags.h functions for kernels
built to support pre-MIPS32 / pre-MIPS64 Release 2 processors.
- Fix the interrupt number of the MIPS Malta's CBUS UART."
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: Malta: Fix interupt number of CBUS UART.
MIPS: Make irqflags.h functions preempt-safe for non-mipsr2 cpus
MIPS: Remove irqflags.h dependency from bitops.h
MIPS: bitops.h: Change use of 'unsigned short' to 'int'
MIPS: compat: Delete now unused TIF_32BIT.
MIPS: compat: Implement is_compat_task() by testing for 32-bit address space.
MIPS: compat: Fix use of TIF_32BIT_ADDR vs _TIF_32BIT_ADDR
Linus Torvalds [Wed, 14 Nov 2012 21:44:04 +0000 (13:44 -0800)]
Merge branch 'for-3.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
Pull cgroup fixes from Tejun Heo:
"This contains two fix patches for device_cgroup. One fixes a
regression introduced earlier in 3.7 cycle where device_cgroup could
try to dereference the NULL parent of the root cgroup. The other one
is RCU usage fix."
Dave Chinner [Mon, 12 Nov 2012 11:53:57 +0000 (22:53 +1100)]
xfs: remove xfs_flushinval_pages
It's just a simple wrapper around VFS functionality, and is actually
bugging in that it doesn't remove mappings before invalidating the
page cache. Remove it and replace it with the correct VFS
functionality.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Andrew Dahl <adahl@sgi.com> Signed-off-by: Ben Myers <bpm@sgi.com>
Dave Chinner [Mon, 12 Nov 2012 11:53:56 +0000 (22:53 +1100)]
xfs: remove xfs_flush_pages
It is a complex wrapper around VFS functions, but there are VFS
functions that provide exactly the same functionality. Call the VFS
functions directly and remove the unnecessary indirection and
complexity.
We don't need to care about clearing the XFS_ITRUNCATED flag, as
that is done during .writepages. Hence is cleared by the VFS
writeback path if there is anything to write back during the flush.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Andrew Dahl <adahl@sgi.com> Signed-off-by: Ben Myers <bpm@sgi.com>
Dave Chinner [Mon, 12 Nov 2012 11:53:55 +0000 (22:53 +1100)]
xfs: remove xfs_wait_on_pages()
It's just a simple wrapper around a VFS function that is only called
by another function in xfs_fs_subr.c. Remove it and call the VFS
function directly.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Andrew Dahl <adahl@sgi.com> Signed-off-by: Ben Myers <bpm@sgi.com>
Dave Chinner [Wed, 14 Nov 2012 06:42:47 +0000 (17:42 +1100)]
xfs: remove xfs_tosspages
It's a buggy, unnecessary wrapper that is duplicating
truncate_pagecache_range().
When replacing the call in xfs_change_file_space(), also ensure that
the length being allocated/freed is always positive before making
any changes. These checks are done in the lower extent manipulation
functions, too, but we need to do them before any page cache
operations.
Reported-by: Andrew Dahl <adahl@sgi.com> Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-By: Andrew Dahl <adahl@sgi.com> Signed-off-by: Ben Myers <bpm@sgi.com>
Paul Mackerras [Wed, 14 Nov 2012 08:15:47 +0000 (19:15 +1100)]
TTY: hvc_console, fix port reference count going to zero prematurely
Commit bdb498c20040 "TTY: hvc_console, add tty install" took the port
refcounting out of hvc_open()/hvc_close(), but failed to remove the
kref_put() and tty_kref_put() calls in hvc_hangup() that were there to
remove the extra references that hvc_open() had taken.
The result was that doing a vhangup() when the current terminal was
a hvc_console, then closing the current terminal, would end up calling
destroy_hvc_struct() and making the port disappear entirely. This
meant that Fedora 17 systems would boot up but then not display the
login prompt on the console, and attempts to open /dev/hvc0 would
give a "No such device" error.
This fixes it by removing the extra kref_put() and tty_kref_put() calls.
Len Brown [Thu, 8 Nov 2012 05:48:57 +0000 (00:48 -0500)]
tools/power turbostat: print Watts
Intel's Sandy Bridge and Ivy Bridge processor generations support RAPL (Run-Time-Average-Power-Limiting).
Per the Intel SDM (IntelĀ® 64 and IA-32 Architectures Software Developer Manual)
RAPL provides hardware power information and control via MSRs (Model Specific Registers).
RAPL MSRs are designed primarily as a method to implement power capping.
However, even if power capping is not enabled, the RAPL regsiters
are useful for monitoring system power and operation.
Turbostat now displays the information provided by reading RAPL MSRs.
As always, turbostat never writes any MSRs.
turbostat's default display now includes Watts for hardware that
supports RAPL:
The Pkg_W column shows Watts for each package (socket) in the system.
On multi-socket systems, the system summary on the 1st row shows the total.
The Cor_W column shows Watts due to processors cores.
Core_W is included in Pkg_W.
The optional GFX_W column shows Watts due to the graphics "un-core".
GFX_W is included in Pkg_W.
The optional PKG_% column shows the % of time in the measurement interval that
RAPL power limiting is in effect.
Note that the RAPL energy counters have some limitations.
First hardware updates the countesr about once every milli-second.
This is fine for typical turbostat measurement intervals > 1 sec.
However, when turbostat is used to measure events that approach
1ms, the counters are less useful.
Second, the energy counters are 32-bits long and subject to wrapping.
For example, the counter increments in 15 micro-Joule units on my
local server, and the part could (in theory) consume energy at
its TDP specification of 130 Watts. Here the 32-bit Joule counter
coult wrap as soon as 8 minutes.
Turbostat detects and handles up to 1 counter overflow per interval.
But when the measurement interval exceeds the guaranteed
counter range, we can't detect if more than 1 overflow occured.
So in this case turbostat indicates that the results are
in question by replacing the fractional part of the result
with "**":
Pkg_W Cor_W GFX_W
3** 0** 0**
Third, the RAPL counters are energy (Joule) counters -- they sum up
weighted events in the package to estimate energy consumed. They are
not analong power (Watt) meters. In practice, they tend to under-count
because they don't cover every possible use of energy in the package.
Also, the accuracy of the RAPL counters will vary between product generations,
and between SKU's in the same product generation.
turbostat's -v option now displays per-Package Thermal Design Power (TDP).
This is the specification for the part's maximum power consumption.
eg. on a 2-package SNB-Xeon system:
Hauke Mehrtens [Sun, 4 Nov 2012 22:13:09 +0000 (23:13 +0100)]
brcmfmac: fix typo in CONFIG_BRCMISCAN
The old ifdef CONFIG_BRCMFISCAN looks wrong to me and it makes more
sense when CONFIG_BRCMISCAN is used.
This patch was just compile tested by me, but not runtime tested.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Shubhrajyoti D [Mon, 5 Nov 2012 12:23:43 +0000 (17:53 +0530)]
i2c: omap: cleanup the sysc write
Currently after the reset the sysc is written with hardcoded values.
The patch reads the sysc register and writes back the same value
after reset.
- Some unnecessary rev checks can be optimised.
- Also due to whatever reason the hwmod flags are changed
we will not reset the values.
- In some of the cases the minor values of the 2430 register
is different(0x37) in that case the autoidle setting may be missed.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Shubhrajyoti D [Mon, 5 Nov 2012 12:23:42 +0000 (17:53 +0530)]
i2c: omap: Restore i2c context always
Currently the restore is done based on the flag
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE.
This helps the following
- The driver is always capable of restoring regardless
of the off mode support being there or not.
- While testing omap2430 it is found that in case of certain
error paths (timeout) a reset is done. However the restore
never happens as it is dependent on the POSTIDLE flag.
The other option would be to call a restore in the reset
case. As there are only a few registers to be restored
the penalty in the idle case should not be much.
Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Shubhrajyoti D [Mon, 5 Nov 2012 12:23:41 +0000 (17:53 +0530)]
i2c: omap: make reset a seperate function
Implement reset as a separate function.
This will enable us to make sure that we don't do the
calculation again on every transfer.
Also at probe the reset is not added as the hwmod is doing that
for us.
Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Shubhrajyoti D [Mon, 5 Nov 2012 12:23:40 +0000 (17:53 +0530)]
i2c: omap: re-factor omap_i2c_init function
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Shubhrajyoti D [Mon, 5 Nov 2012 12:23:39 +0000 (17:53 +0530)]
ARM: i2c: omap: Remove the i207 errata flag
The commit [i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207]
uses the revision id instead of the flag. So the flag can be safely removed.
Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Shubhrajyoti D [Mon, 5 Nov 2012 12:23:36 +0000 (17:53 +0530)]
i2c: omap: Fix the revision register read
The revision register on OMAP4 is a 16-bit lo and a 16-bit
hi. Currently the driver reads only the lower 8-bits.
Fix the same by preventing the truncating of the rev register
for OMAP4.
Also use the scheme bit ie bit-14 of the hi register to know if it
is OMAP_I2C_IP_VERSION_2.
On platforms previous to OMAP4 the offset 0x04 is IE register whose
bit-14 reset value is 0, the code uses the same to its advantage.
Also since the omap_i2c_read_reg uses reg_map_ip_* a raw_readw is done
to fetch the revision register.
The dev->regs is populated after reading the rev_hi. A NULL check
has been added in the resume handler to prevent the access before
the setting of the regs.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Some GPIO expanders need some early pin control muxing. Due to
legacy boards sometimes the driver uses subsys_initcall instead of
module_init. This patch takes advantage of defer probe feature
and pin control in order to wait until pin control probing before
GPIO driver probing. It has been tested on OMAP5 board with TCA6424
driver.
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com> Acked-by: Shubhrajyoti D <shubhrajyoti@ti.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Felipe Balbi [Wed, 14 Nov 2012 14:22:45 +0000 (16:22 +0200)]
i2c: omap: ensure writes to dev->buf_len are ordered
if we allow compiler reorder our writes, we could
fall into a situation where dev->buf_len is reset
for no apparent reason.
This bug was found with a simple script which would
transfer data to an i2c client from 1 to 1024 bytes
(a simple for loop), when we got to transfer sizes
bigger than the fifo size, dev->buf_len was reset
to zero before we had an oportunity to handle XDR
Interrupt. Because dev->buf_len was zero, we entered
omap_i2c_transmit_data() to transfer zero bytes,
which would mean we would just silently exit
omap_i2c_transmit_data() without actually writing
anything to DATA register. That would cause XDR
IRQ to trigger forever and we would never transfer
the remaining bytes.
After adding the memory barrier, we also drop resetting
dev->buf_len to zero in omap_i2c_xfer_msg() because
both omap_i2c_transmit_data() and omap_i2c_receive_data()
will act until dev->buf_len reaches zero, rendering the
other write in omap_i2c_xfer_msg() redundant.
This patch has been tested with pandaboard for a few
iterations of the script mentioned above.
Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Josh Cartwright [Wed, 31 Oct 2012 19:56:14 +0000 (13:56 -0600)]
ARM: zynq: add clk binding support to the ttc
Add support for retrieving TTC configuration from device tree. This
includes the ability to pull information about the driving clocks from
the of_clk bindings.
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com> Acked-by: Michal Simek <michal.simek@xilinx.com>
Josh Cartwright [Tue, 13 Nov 2012 23:26:48 +0000 (17:26 -0600)]
clk: Add support for fundamental zynq clks
Provide simplified models for the necessary clocks on the zynq-7000
platform. Currently, the PLLs, the CPU clock network, and the basic
peripheral clock networks (for SDIO, SMC, SPI, QSPI, UART) are modelled.
OF bindings are also provided and documented.
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Acked-by: Mike Turquette <mturquette@linaro.org> Acked-by: Michal Simek <michal.simek@xilinx.com>
Takashi Iwai [Tue, 13 Nov 2012 10:22:48 +0000 (11:22 +0100)]
ALSA: usb-audio: Fix mutex deadlock at disconnection
The recent change for USB-audio disconnection race fixes introduced a
mutex deadlock again. There is a circular dependency between
chip->shutdown_rwsem and pcm->open_mutex, depicted like below, when a
device is opened during the disconnection operation:
B. snd_pcm_open() ->
pcm->open_mutex ->
snd_usb_pcm_open() ->
chip->shutdown_rwsem (read)
Since the chip->shutdown_rwsem protection in the case A is required
only for turning on the chip->shutdown flag and it doesn't have to be
taken for the whole operation, we can reduce its window in
snd_usb_audio_disconnect().
Paul Walmsley [Tue, 6 Nov 2012 16:31:32 +0000 (16:31 +0000)]
Revert "ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints"
This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc
(ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints).
This commit causes I2C timeouts to appear on several OMAP3430/3530-based
boards:
Will Deacon [Mon, 12 Nov 2012 19:19:35 +0000 (19:19 +0000)]
arm64: mm: update max_dma32 before calculating size of NORMAL zone
Commit f483a853b0b9 ("arm64: mm: fix booting on systems with no memory
below 4GB") sets max_dma32 to the minimum of the maximum pfn and
MAX_DMA32_PFN. This value is later used as the base of the NORMAL zone,
which is incorrect when MAX_DMA32_PFN is below the minimum pfn (i.e. all
memory is above 4GB).
This patch fixes the problem by ensuring that max_dma32 is always set to
the end of the DMA32 zone.
Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Catalin Marinas [Wed, 24 Oct 2012 15:34:02 +0000 (16:34 +0100)]
arm64: Make the user fault reporting more specific
For user space faults the kernel reports "unhandled page fault" and it
gives the ESR value. With this patch the error message looked up in the
fault info array to give a better description.