Grazvydas Ignotas [Sat, 19 Apr 2014 18:06:09 +0000 (21:06 +0300)]
wl1251: improve PS report handling
Surendra Patil [Tue, 4 Mar 2014 08:18:52 +0000 (00:18 -0800)]
Drivers:net:wireless:ti:wl1251: Fixed Sparse invalid assignment warning
Sparse warns about invalid assignment in
drivers/net/wireless/wl1251/cmd.c:451:42: warning: invalid assignment: |=
drivers/net/wireless/wl1251/cmd.c:451:42: left side has type restricted __le16
drivers/net/wireless/wl1251/cmd.c:451:42: right side has type int
Hence type converted right side to __le16.
Signed-off-by: Surendra Patil <surendra.tux@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
David Gnedt [Tue, 7 Jan 2014 12:04:53 +0000 (13:04 +0100)]
wl1251: fix scan behaviour while not associated
With a dissasociated card I often encoutered very long scan delays.
My guess is that it has something to do with the cards DTIM handling and
another firmware bug mentioned in the TI WLAN driver, which is described as
the card may never end scanning if the channel is overloaded because it
can't send probe requests. I think the firmware somehow also tries to
receive DTIM messages when the BSSID is not set. Therefore most of the time
it waits for DTIM messages and can't do scanning work.
Anyway we can workaround this misbehaviour by setting the HIGH_PRIORITY
bit for scans in disassociated state.
Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ivaylo Dimitrov [Sat, 1 Mar 2014 12:52:06 +0000 (14:52 +0200)]
wl1251: use skb_trim to make skb shorter
the current code is directly setting skb->len, which is not correct and
brings problems with HAVE_EFFICIENT_UNALIGNED_ACCESS enabled in config
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
David Gnedt [Tue, 7 Jan 2014 12:11:27 +0000 (13:11 +0100)]
wl1251: enforce changed hw encryption support on monitor state change
The firmware doesn't support per packet encryption selection, so disable hw
encryption support completely while a monitor interface is present to support
injection of packets (which shouldn't get encrypted by hw).
To enforce the changed hw encryption support force a disassociation on
non-monitor interfaces.
For disassociation a workaround using hw connection monitor is employed,
which temporary enables hw connection manager flag.
Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
David Gnedt [Tue, 7 Jan 2014 12:10:51 +0000 (13:10 +0100)]
wl1251: disable retry and ACK policy for injected packets
Set the retry limit to 0 and disable the ACK policy for injected packets.
Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
David Gnedt [Tue, 7 Jan 2014 12:10:14 +0000 (13:10 +0100)]
wl1251: enable tx path in monitor mode if necessary for packet injection
If necessary enable the tx path in monitor mode for packet injection using
the JOIN command with BSS_TYPE_STA_BSS and zero BSSID.
Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
David Gnedt [Tue, 7 Jan 2014 12:09:42 +0000 (13:09 +0100)]
wl1251: fix channel switching in monitor mode
Use the ENABLE_RX command for channel switching when no interface is present
(monitor mode only).
The advantage of ENABLE_RX is that it leaves the tx data path disabled in
firmware, whereas the usual JOIN command seems to transmit some frames at
firmware level.
Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
David Gnedt [Tue, 7 Jan 2014 12:09:06 +0000 (13:09 +0100)]
wl1251: disable power saving in monitor mode
Force power saving off while monitor interface is present.
Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
David Gnedt [Tue, 7 Jan 2014 12:08:30 +0000 (13:08 +0100)]
wl1251: implement multicast address filtering (fwd)
Port multicast address filtering from wl1271 driver.
It sets up the hardware multicast address filter in configure_filter() with
addresses supplied through prepare_multicast().
Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
David Gnedt [Tue, 7 Jan 2014 12:07:52 +0000 (13:07 +0100)]
wl1251: configure hardware en-/decryption for monitor mode
Disable hardware encryption (DF_ENCRYPTION_DISABLE) and decryption
(DF_SNIFF_MODE_ENABLE) via wl1251_acx_feature_cfg while monitor interface is
present.
Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
David Gnedt [Tue, 7 Jan 2014 12:06:58 +0000 (13:06 +0100)]
wl1251: split RX and TX data path initialisation
Split up data path initialisation into RX and TX data path initialisation
functions. This change is required for channel switching in monitor mode.
Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
David Gnedt [Tue, 7 Jan 2014 12:06:24 +0000 (13:06 +0100)]
wl1251: implement hardware ARP filtering
Update hardware ARP filter configuration on BSS_CHANGED_ARP_FILTER
notification from mac80211.
Ported from wl1271 driver.
Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Grazvydas Ignotas [Wed, 16 Apr 2014 00:14:41 +0000 (03:14 +0300)]
ARM: OMAP3: PM: enable sys_clkreq signalling
Grazvydas Ignotas [Tue, 15 Apr 2014 23:40:51 +0000 (02:40 +0300)]
pandora: add basic power scripts
Grazvydas Ignotas [Tue, 15 Apr 2014 23:38:26 +0000 (02:38 +0300)]
pandora: remove unused i2c_boardinfo
Grazvydas Ignotas [Tue, 15 Apr 2014 23:36:24 +0000 (02:36 +0300)]
mfd: twl4030-power: warn anout P3 order, not P12
Grazvydas Ignotas [Tue, 15 Apr 2014 21:43:41 +0000 (00:43 +0300)]
hwmod: disable reset wait code
causes data abort on venc init here, probably bad clock/hwmod data
Paul Walmsley [Thu, 19 Apr 2012 10:03:50 +0000 (04:03 -0600)]
ARM: OMAP2/3: hwmod data: update old names
Some of the 2xxx and 3xxx hwmod data files use the old naming style
for hwmods, ending in a "_hwmod". These names are used by the OMAP
integration code to map hwmods to platform_devices, so they need to be
consistent, or the platform_devices won't be created. Remove the
_hwmod suffix to conform with the rest of the OMAP SoC data.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tero Kristo [Thu, 10 Apr 2014 23:47:09 +0000 (16:47 -0700)]
ARM: OMAP3: PM: remove access to PRM_VOLTCTRL register
There is a solitary write to this register every wakeup from off-mode,
which isn't doing anything, so remove it.
Also note that modifying this register trashes any attempted
voltage scaling configuration and the change probably should
never have gotten merged in the first place.
[notasas@gmail.com: 3.2 backport]
Cc: Nishanth Menon <nm@ti.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[tony@atomide.com: updated comments to describe regression]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Jon Hunter [Fri, 6 Jul 2012 21:45:04 +0000 (16:45 -0500)]
ARM: OMAP: Fix timer posted mode support
Currently the dmtimer posted mode is being enabled when the function
omap_dm_timer_enable_posted() is called. This function is only being called
for OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence,
for OMAP2+ timers that are NOT being used as a system timer, posted mode is
not enabled but the "timer->posted" variable is still set (incorrectly) in
the omap_dm_timer_prepare() function.
This is a regression introduced by commit
3392cdd3 (ARM: OMAP: dmtimer:
switch-over to platform device driver) which was before the
omap_dm_timer_enable_posted() function was introduced. Although this is a
regression from the original code it only impacts performance and so is not
needed for stable.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Conflicts:
arch/arm/plat-omap/dmtimer.c
Jon Hunter [Thu, 27 Sep 2012 17:47:43 +0000 (12:47 -0500)]
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer
registers after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode
(TSICR [2].POSTED=1), due to internal resynchronizations, values read in
TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
(L4) goes from stopped to active may not return the expected values. The
most common event leading to this situation occurs upon wake up from
idle.
GPTimer non-posted synchronization mode is not impacted by this
limitation.
Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock
domain
3). Use no-idle mode when the timer is active
Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead for configuring and reading the timers as the CPU has to wait
for accesses to be re-synchronised within the timer. However, disabling
posted mode guarantees correct operation.
Please note that it is safe to use posted mode for timers if the counter
(TCRR) and capture (TCARx) registers will never be read. An example of
this is the clock-event system timer. This is used by the kernel to
schedule events however, the timers counter is never read and capture
registers are not used. Given that the kernel configures this timer
often yet never reads the counter register it is safe to enable posted
mode in this case. Hence, for the timer used for kernel clock-events,
posted mode is enabled by overriding the errata for devices that are
impacted by this defect.
For drivers using the timers that do not read the counter or capture
registers and wish to use posted mode, can override the errata and
enable posted mode by making the following function calls.
__omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
__omap_dm_timer_enable_posted(timer);
Both dmtimers and watchdogs are impacted by this defect this patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does not read the counter register and so no workaround is necessary.
Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
using a GP timer as a clock-source timer to guarantee correct operation.
This is not necessary for OMAP24xx devices but the default clock-source
timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
and so should not have any impact. This should be re-visited for future
devices if this errata is fixed.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
devices.
[notasas@gmail.com: 3.2 backport]
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Conflicts:
arch/arm/mach-omap2/timer.c
arch/arm/plat-omap/dmtimer.c
arch/arm/plat-omap/include/plat/dmtimer.h
Jon Hunter [Thu, 27 Sep 2012 16:49:45 +0000 (11:49 -0500)]
ARM: OMAP: Add DMTIMER definitions for posted mode
For OMAP2+ devices, when using DMTIMERs for system timers (clock-events and
clock-source) the posted mode configuration of the timers is used. To allow
the compiler to optimise the functions for configuring and reading the system
timers, the posted flag variable is hard-coded with the value 1. To make it
clear that posted mode is being used add some definitions so that it is more
readable.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Conflicts:
arch/arm/plat-omap/include/plat/dmtimer.h
Vaibhav Hiremath [Mon, 23 Jan 2012 06:48:14 +0000 (12:18 +0530)]
ARM: OMAP2+: timer: Fix crash due to wrong arg to __omap_dm_timer_read_counter
Commit
2f0778af (ARM: 7205/2: sched_clock: allow sched_clock to be
selected at runtime) had a typo for the case when CONFIG_OMAP_32K_TIMER
is not set.
In dmtimer_read_sched_clock(), wrong argument was getting passed to
__omap_dm_timer_read_counter() function call; instead of "&clksrc",
we were passing "clksrc.io_base", which results into kernel crash.
To reproduce kernel crash, just disable the CONFIG_OMAP_32K_TIMER config
option (and DEBUG_LL) and build/boot the kernel.
This will use dmtimer as a kernel clocksource and lead to kernel
crash during boot -
[ 0.000000] OMAP clocksource: GPTIMER2 at
26000000 Hz
[ 0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every
165191ms
[ 0.000000] Unable to handle kernel paging request at virtual address
00030ef1
[ 0.000000] pgd =
c0004000
[ 0.000000] [
00030ef1] *pgd=
00000000
[ 0.000000] Internal error: Oops: 5 [#1] SMP
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 Not tainted (3.3.0-rc1-11574-g0c76665-dirty #3)
[ 0.000000] PC is at dmtimer_read_sched_clock+0x18/0x4c
[ 0.000000] LR is at update_sched_clock+0x10/0x84
[ 0.000000] pc : [<
c00243b8>] lr : [<
c0018684>] psr:
200001d3
[ 0.000000] sp :
c0641f38 ip :
c0641e18 fp :
0000000a
[ 0.000000] r10:
151c3303 r9 :
00000026 r8 :
76276259
[ 0.000000] r7 :
00028547 r6 :
c065ac80 r5 :
431bde82 r4 :
c0655968
[ 0.000000] r3 :
00030ef1 r2 :
fb032000 r1 :
00000028 r0 :
00000001
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Marc Zyngier [Thu, 15 Dec 2011 11:19:23 +0000 (12:19 +0100)]
ARM: 7205/2: sched_clock: allow sched_clock to be selected at runtime
sched_clock() is yet another blocker on the road to the single
image. This patch implements an idea by Russell King:
http://www.spinics.net/lists/linux-omap/msg49561.html
Instead of asking the platform to implement both sched_clock()
itself and the rollover callback, simply register a read()
function, and let the ARM code care about sched_clock() itself,
the conversion to ns and the rollover. sched_clock() uses
this read() function as an indirection to the platform code.
If the platform doesn't provide a read(), the code falls back
to the jiffy counter (just like the default sched_clock).
This allow some simplifications and possibly some footprint gain
when multiple platforms are compiled in. Among the drawbacks,
the removal of the *_fixed_sched_clock optimization which could
negatively impact some platforms (sa1100, tegra, versatile
and omap).
Tested on 11MPCore, OMAP4 and Tegra.
Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Colin Cross <ccross@android.com>
Cc: Erik Gilling <konkers@android.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Alessandro Rubini <rubini@unipv.it>
Cc: STEricsson <STEricsson_nomadik_linux@list.st.com>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Cc: Ben Dooks <ben-linux@fluff.org>
Tested-by: Jamie Iles <jamie@jamieiles.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Krzysztof Halasa <khc@pm.waw.pl>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Vaibhav Hiremath [Wed, 9 May 2012 17:07:05 +0000 (10:07 -0700)]
ARM: OMAP2+: Replace space with underscore in the name field of system timers
Depending on the bootloader, passing command-line arguments
with spaces may have issues. Some bootloaders doesn't seem
to pass along the quotes, passing only 'gp' part of the string,
which leads to wrong override configuration.
The only affected kernel parameter configuration for OMAP family
is "clocksource=", used to override kernel clocksource.
So this patch changes "gp timer" => "gp_timer", for clockevent,
clocksource and timer irq_handler.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tarun Kanti DebBarma [Tue, 8 May 2012 05:55:30 +0000 (23:55 -0600)]
ARM: OMAP2+: dmtimer: cleanup iclk usage
We do not use iclk anywhere in the dmtimer driver and so removing it.
Hence removing the timer iclk entries from OMAP4 clkdev table as well.
Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Paul Walmsley [Mon, 3 Sep 2012 17:50:43 +0000 (11:50 -0600)]
ARM: OMAP3xxx: clockdomain: fix software supervised wakeup/sleep
Commit
4da71ae6 ("OMAP: clockdomain: Arch specific funcs for
clkdm_clk_enable/disable") called the OMAP2xxx-specific functions for
clockdomain wakeup and sleep. This would probably have broken
software-supervised clockdomain wakeup and sleep on OMAP3.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Acked-by: Rajendra Nayak <rnayak@ti.com>
Tero Kristo [Tue, 25 Sep 2012 16:05:32 +0000 (19:05 +0300)]
ARM: OMAP: clockdomain: Fix locking on _clkdm_clk_hwmod_enable / disable
Previously the code only acquired spinlock after increasing / decreasing
the usecount value, which is wrong. This leaves a small window where
a task switch may occur between the check of the usecount and the actual
wakeup / sleep of the domain. Fixed by moving the spinlock locking before
the usecount access. Left the usecount as atomic_t if someone wants an
easy access to the parameter through atomic_read.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Sat, 26 Jan 2013 07:58:14 +0000 (00:58 -0700)]
ARM: OMAP2+: clockdomain: add pwrdm_state_switch() call to clkdm_sleep()
In clkdm_sleep(), the powerdomain should be eligible to switch power
states right after the call to the low-level clockdomain sleep
function. We should have been tracking that with the
pwrdm_state_switch() code, but we weren't, for whatever reason. Fix that.
This resolves the "pwrdm state mismatch(cam_pwrdm) 3 != 0" that appears
during the OMAP4460 Pandaboard-ES PM test, e.g. here:
http://www.pwsan.com/omap/testlogs/test_v3.8-rc5/
20130126003323/pm/4460pandaes/4460pandaes_log.txt
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Illia Smyrnov [Wed, 5 Feb 2014 15:06:09 +0000 (17:06 +0200)]
ARM: OMAP4: hwmod: Fix SOFTRESET logic for OMAP4
Commit 313a76e (ARM: OMAP2+: hwmod: Fix SOFTRESET logic) introduced
softreset bit cleaning right after set one. It is caused L3 error for
OMAP4 ISS because ISS register write occurs when ISS reset process is in
progress. Avoid this situation by cleaning softreset bit later, when reset
process is successfully finished.
Signed-off-by: Illia Smyrnov <illia.smyrnov@globallogic.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tero Kristo [Tue, 30 Oct 2012 04:02:13 +0000 (22:02 -0600)]
ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
When waking up from off-mode, some IP blocks are reset automatically by
hardware. For this reason, software must wait until the reset has
completed before attempting to access the IP block.
This patch fixes for example the bug introduced by commit
6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
to SYSCONFIG register"), in which the MMC IP block is reset during
off-mode entry, but the code expects the module to be already available
during the execution of context restore.
This version includes a fix from Kevin Hilman <khilman@ti.com> for
GPIO problems on the 37xx EVM - thanks Kevin.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Venkatraman S <svenkatr@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: moved softreset wait code into separate function; call
from top of _enable_sysc() rather than the bottom; include fix from Kevin
Hilman for GPIO sluggishness]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Conflicts:
arch/arm/mach-omap2/omap_hwmod.c
Paul Walmsley [Sat, 26 Jan 2013 07:58:13 +0000 (00:58 -0700)]
ARM: OMAP3xxx: CPUIdle: optimize __omap3_enter_idle()
Avoid programming the MPU and CORE powerdomain next-power-state
registers if those powerdomains will never enter low-power states
(e.g., the state that people refer to as "C1").
To avoid making assumptions about CPUIdle states based on their order
in the list, use a flag to mark CPUIdle states that don't enter
powerdomain low-power states.
Avoid a previous-power-state register read on the MPU powerdomain
unless we know that the MPU was supposed to go OFF during the last
state transition. Previous-power-state register reads can be very
expensive, so it's worth avoiding these when possible.
Since the CORE_L3 clockdomain can't go inactive unless the MPU is active,
there's little point blocking autoidle on the CORE_L3 clockdomain in "C1"
state, since we've programmed the MPU clockdomain to stay active.
Remove the unnecessary code.
[notasas@gmail.com: 3.2 backport]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Conflicts:
arch/arm/mach-omap2/cpuidle34xx.c
Santosh Shilimkar [Sat, 3 Sep 2011 17:08:27 +0000 (22:38 +0530)]
ARM: OMAP3: CPUidle: Make use of CPU PM notifiers
Save VFP CPU context using CPU PM notifier chain. VFP context
is lost when CPU hits OFF state.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Jean Pihet [Fri, 1 Jun 2012 15:11:08 +0000 (17:11 +0200)]
ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
For a power domain to idle all the clock domains in it must idle.
This patch implements an optimization of the cpuidle code by
denying and later allowing only the first registered clock domain
of a power domain, and so optimizes the latency of the low power code.
The functions _cpuidle_allow_idle and _cpuidle_deny_idle are
not used anymore and so are removed.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Conflicts:
arch/arm/mach-omap2/cpuidle34xx.c
Jean Pihet [Fri, 1 Jun 2012 15:11:07 +0000 (17:11 +0200)]
ARM: OMAP3: PM: cpuidle: optimize the PER latency in C1 state
One of the main contributors of the low power code latency is
the PER power domain. To optimize the high-performance and
low-latency C1 state, prevent any PER state which is lower
than the CORE state in C1.
Reported and suggested by Kevin Hilman.
Reported-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Conflicts:
arch/arm/mach-omap2/cpuidle34xx.c
Santosh Shilimkar [Mon, 11 Feb 2013 13:59:45 +0000 (19:29 +0530)]
ARM: OMAP2+: PM: Remove bogus fiq_[enable/disable] tuple
On OMAP platform, FIQ is reserved for secure environment only. If at all
the FIQ needs to be disabled, it involves going through security
API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
On GP devices too, the fiq is disabled for non-secure software.
So just get rid of it.
[notasas@gmail.com: 3.2 backport]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Conflicts:
arch/arm/mach-omap2/cpuidle34xx.c
arch/arm/mach-omap2/cpuidle44xx.c
arch/arm/mach-omap2/pm24xx.c
arch/arm/mach-omap2/pm34xx.c
arch/arm/mach-omap2/pm44xx.c
Ruslan Bilovol [Thu, 14 Feb 2013 11:55:24 +0000 (13:55 +0200)]
ARM: OMAP2+: Export SoC information to userspace
In some situations it is useful for userspace to
know some SoC-specific information. For example,
this may be used for deciding what kernel module to
use or how to better configure some settings etc.
This patch exports OMAP SoC information to userspace
using existing in Linux kernel SoC infrastructure.
This information can be read under
/sys/devices/socX directory
[notasas@gmail.com: 3.2 backport]
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
[tony@atomide.com: updated for multiplatform changes]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Conflicts:
arch/arm/mach-omap2/Kconfig
arch/arm/mach-omap2/common.h
arch/arm/mach-omap2/io.c
Ruslan Bilovol [Thu, 14 Feb 2013 11:55:23 +0000 (13:55 +0200)]
ARM: OMAP2+: SoC name and revision unification
This is a long story where for each new generation of
OMAP we used different approaches for creating
strings for SoCs names and revisions that this patch
fixes. It makes future exporting of this information
to SoC infrastructure easier.
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Conflicts:
arch/arm/mach-omap2/id.c
Vaibhav Hiremath [Mon, 19 Dec 2011 10:20:15 +0000 (15:50 +0530)]
ARM: OMAP2+: split omap2/3/4_check_revision function
We need to detect the SoC revision early, but the SoC
feature detection can be done later on. In order to allow
further clean-up later on, this patch separates the SoC
revision check from the SoC feature check.
This patch doesn't change functionality or behavior of the code
execution; it barely cleans up the code and splits into SoC
specific implementation for Rev ID and feature detection.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Conflicts:
arch/arm/mach-omap2/id.c
arch/arm/mach-omap2/io.c
arch/arm/plat-omap/include/plat/cpu.h
Vaibhav Hiremath [Mon, 19 Dec 2011 10:20:14 +0000 (15:50 +0530)]
ARM: OMAP2+: Make cpu_rev static global variable
As part of omap revision code cleanup, make cpu_rev
variable static global to the file (id.c). This is
needed so we can split the SoC detection from SoC
feature detection in the following patch. Also move
omap3_cpuinfo function a bit as that will be shared
by other omap3 like SoCs.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Conflicts:
arch/arm/mach-omap2/id.c
Axel Lin [Tue, 20 Mar 2012 08:32:39 +0000 (16:32 +0800)]
drivers/base: Remove unneeded spin_lock_init call for soc_lock
soc_lock is already initialized by DEFINE_SPINLOCK.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lee Jones [Mon, 6 Feb 2012 19:22:22 +0000 (11:22 -0800)]
drivers/base: add bus for System-on-Chip devices
Traditionally, any System-on-Chip based platform creates a flat list
of platform_devices directly under /sys/devices/platform.
In order to give these some better structure, this introduces a new
bus type for soc_devices that are registered with the new
soc_device_register() function. All devices that are on the same
chip should then be registered as child devices of the soc device.
The soc bus also exports a few standardised device attributes which
allow user space to query the specific type of soc.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Conflicts:
drivers/base/Kconfig
Grazvydas Ignotas [Mon, 14 Apr 2014 00:23:48 +0000 (03:23 +0300)]
ASoC: twl4030: pandora hack: remove 96kHz
256fs clock becomes 128fs for 96kHz, so we effectively get half speed
playback. Also pcm1773 is only specified for upto 50kHz.
XXX: need to find a proper way to do this in mainline..
Grazvydas Ignotas [Mon, 14 Apr 2014 00:23:41 +0000 (03:23 +0300)]
ASoC: pandora: set divider correctly for higher bit depths
Jon Hunter [Fri, 23 Aug 2013 10:40:23 +0000 (04:40 -0600)]
ARM: OMAP2+: Only write the sysconfig on idle when necessary
Currently, whenever we idle a device _idle_sysc() is called and writes to the
devices SYSCONFIG register to set the idle mode. A lot devices are using the
smart-idle mode and so the write to the SYSCONFIG register is programming the
same value that is already stored in the register.
Writes to the devices SYSCONFIG register can be slow, for example, writing to
the DMTIMER SYSCONFIG register takes 3 interface clock cycles and 3 functional
clock cycles. If the DMTIMER is using the slow 32kHz functional clock this can
take ~100us.
Furthermore, during boot on an OMAP4430 panda board, I see that there are 100
calls to _idle_sysc(), however, only 3 out of the 100 calls actually write
the SYSCONFIG register with a new value.
Therefore, to avoid unnecessary writes to device SYSCONFIG registers when
idling the device, only write the value if the value has changed. It should be
safe to do this on idle as the context of the register will never be lost while
the device is active.
Verified that suspend, CORE off and retention states are working with this
change on OMAP3430 Beagle board.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Rajendra Nayak [Wed, 15 May 2013 14:48:37 +0000 (20:18 +0530)]
ARM: OMAP2+: hwmod: Fix sidle programming in _enable_sysc()/_idle_sysc()
_enable_sysc() and _idle_sysc() handle the midle mode programming correctly
and program HWMOD_IDLEMODE_SMART or HWMOD_IDLEMODE_SMART_WKUP respectively
for supported IPs (The ones which support hardware controlled midle modes)
However the same programming logic is missing when it comes to sidle mode
programming. Here they seem to just set HWMOD_IDLEMODE_SMART (Again for the
ones which support hardware controlled sidle modes)
This problem was hidden due to the fact that a call to _enable_wakeup()
in those same functions would overwrite the idlemodes and program them
correctly (to HWMOD_IDLEMODE_SMART_WKUP in the supported cases)
So fix the sidlemode handling correctly in these functions and handle the
_enable_wakeup() for SIDLEMODE supported IPs same as the way its handled
for MIDLEMODE supported ones.
Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org> # OMAP4/Panda
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Conflicts:
arch/arm/mach-omap2/omap_hwmod.c
Paul Walmsley [Wed, 4 Jul 2012 11:22:53 +0000 (05:22 -0600)]
ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer
Kevin discovered that commit
c8d82ff68fb6873691536cf33021977efbf5593c
("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database") broke CORE idle on OMAP3. This prevents device low power
states.
The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and so the hwmod code keeps the IP block in
no-idle mode while it is active. This in turn prevents the WKUP
clockdomain from transitioning to idle. There is a hardcoded sleep
dependency that prevents the CORE_L3 and CORE_CM clockdomains from
transitioning to idle when the WKUP clockdomain is active[2], so the
chip cannot enter any device low power states.
It turns out that there is no need to take the 32k sync timer out of
idle. The IP block itself probably does not have any native idle
handling at all, due to its simplicity. Furthermore, the PRCM will
never request target idle for this IP block while the kernel is
running, due to the sleep dependency that prevents the WKUP
clockdomain from idling while the CORE_L3 clockdomain is active. So
we can safely leave the 32k sync timer in target-force-idle mode, even
while we continue to access it.
This workaround is implemented by defining a new clockdomain flag,
CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is
guaranteed to be active whenever the MPU is inactive. If an IP
block's main functional clock exists inside this clockdomain, and the
IP block does not support smart-idle modes, then the hwmod code will
place the IP block into target force-idle mode even when enabled. The
WKUP clockdomains on OMAP3/4 are marked with this flag. (On OMAP2xxx,
no OCP header existed on the 32k sync timer.) Other clockdomains also
should be marked with this flag, but those changes are deferred until
a later merge window, to create a minimal fix.
Another theoretically clean fix for this problem would be to implement
PM runtime-based control for 32k sync timer accesses. These PM
runtime calls would need to located in a custom clocksource, since the
32k sync timer is currently used as an MMIO clocksource. But in
practice, there would be little benefit to doing so; and there would
be some cost, due to the addition of unnecessary lines of code and the
additional CPU overhead of the PM runtime and hwmod code - unnecessary
in this case.
Another possible fix would have been to modify the pm34xx.c code to
force the IP block idle before entering WFI. But this would not have
been an acceptable approach: we are trying to remove this type of
centralized IP block idle control from the PM code.
This patch is a collaboration between Kevin Hilman <khilman@ti.com>
and Paul Walmsley <paul@pwsan.com>.
Thanks to Vaibhav Hiremath <hvaibhav@ti.com> for providing comments on
an earlier version of this patch. Thanks to Tero Kristo
<t-kristo@ti.com> for identifying a bug in an earlier version of this
patch. Thanks to Benoît Cousson <b-cousson@ti.com> for identifying
some bugs in several versions of this patch and for implementation
comments.
References:
1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
(SWPU223U), available from:
http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip
2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
(SWPU223U)
3. ibid.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Grazvydas Ignotas [Mon, 14 Apr 2014 00:21:53 +0000 (03:21 +0300)]
net: asix: fix build
Grazvydas Ignotas [Mon, 14 Apr 2014 00:21:39 +0000 (03:21 +0300)]
Revert "Staging: tidspbridge: disable driver"
This reverts commit
2908084d0144ffb5d1a7616348a86acac5247a10.
Even if it's unmaintained and bugged, it's still useful for us..
notaz [Sun, 13 Apr 2014 16:21:38 +0000 (19:21 +0300)]
Merge branch 'stable-3.2' into pandora-3.2
Conflicts:
arch/arm/mm/proc-v7.S
Ben Hutchings [Wed, 9 Apr 2014 01:20:47 +0000 (02:20 +0100)]
Linux 3.2.57
Martin Schwidefsky [Mon, 3 Feb 2014 16:37:15 +0000 (17:37 +0100)]
s390: fix kernel crash due to linkage stack instructions
commit
8d7f6690cedb83456edd41c9bd583783f0703bf0 upstream.
The kernel currently crashes with a low-address-protection exception
if a user space process executes an instruction that tries to use the
linkage stack. Set the base-ASTE origin and the subspace-ASTE origin
of the dispatchable-unit-control-table to point to a dummy ASTE.
Set up control register 15 to point to an empty linkage stack with no
room left.
A user space process with a linkage stack instruction will still crash
but with a different exception which is correctly translated to a
segmentation fault instead of a kernel oops.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jeff Layton [Fri, 14 Feb 2014 12:20:35 +0000 (07:20 -0500)]
cifs: ensure that uncached writes handle unmapped areas correctly
commit
5d81de8e8667da7135d3a32a964087c0faf5483f upstream.
It's possible for userland to pass down an iovec via writev() that has a
bogus user pointer in it. If that happens and we're doing an uncached
write, then we can end up getting less bytes than we expect from the
call to iov_iter_copy_from_user. This is CVE-2014-0069
cifs_iovec_write isn't set up to handle that situation however. It'll
blindly keep chugging through the page array and not filling those pages
with anything useful. Worse yet, we'll later end up with a negative
number in wdata->tailsz, which will confuse the sending routines and
cause an oops at the very least.
Fix this by having the copy phase of cifs_iovec_write stop copying data
in this situation and send the last write as a short one. At the same
time, we want to avoid sending a zero-length write to the server, so
break out of the loop and set rc to -EFAULT if that happens. This also
allows us to handle the case where no address in the iovec is valid.
[Note: Marking this for stable on v3.4+ kernels, but kernels as old as
v2.6.38 may have a similar problem and may need similar fix]
Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru>
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
[bwh: Backported to 3.2:
- Adjust context
- s/nr_pages/npages/
- s/wdata->pages/pages/
- In case of an error with no data copied, we must kunmap() page 0,
but in neither case should we free anything else]
Thanks to Raphael Geissert for an independent backport that showed some
bugs in my first version.]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Marcelo Tosatti [Fri, 3 Jan 2014 19:00:51 +0000 (17:00 -0200)]
KVM: VMX: fix use after free of vmx->loaded_vmcs
commit
26a865f4aa8e66a6d94958de7656f7f1b03c6c56 upstream.
After free_loaded_vmcs executes, the "loaded_vmcs" structure
is kfreed, and now vmx->loaded_vmcs points to a kfreed area.
Subsequent free_loaded_vmcs then attempts to manipulate
vmx->loaded_vmcs.
Switch the order to avoid the problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1047892
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Marcelo Tosatti [Thu, 19 Dec 2013 17:28:51 +0000 (15:28 -0200)]
KVM: MMU: handle invalid root_hpa at __direct_map
commit
989c6b34f6a9480e397b170cc62237e89bf4fdb9 upstream.
It is possible for __direct_map to be called on invalid root_hpa
(-1), two examples:
1) try_async_pf -> can_do_async_pf
-> vmx_interrupt_allowed -> nested_vmx_vmexit
2) vmx_handle_exit -> vmx_interrupt_allowed -> nested_vmx_vmexit
Then to load_vmcs12_host_state and kvm_mmu_reset_context.
Check for this possibility, let fault exception be regenerated.
BZ: https://bugzilla.redhat.com/show_bug.cgi?id=924916
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Emil Goode [Thu, 13 Feb 2014 18:30:39 +0000 (19:30 +0100)]
net: asix: add missing flag to struct driver_info
commit
d43ff4cd798911736fb39025ec8004284b1b0bc2 upstream.
The struct driver_info ax88178_info is assigned the function
asix_rx_fixup_common as it's rx_fixup callback. This means that
FLAG_MULTI_PACKET must be set as this function is cloning the
data and calling usbnet_skb_return. Not setting this flag leads
to usbnet_skb_return beeing called a second time from within
the rx_process function in the usbnet module.
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Emil Goode [Mon, 31 Mar 2014 15:41:32 +0000 (17:41 +0200)]
net: asix: handle packets crossing URB boundaries
commit
8b5b6f5413e97c3e8bafcdd67553d508f4f698cd upstream.
ASIX AX88772B started to pack data even more tightly. Packets and the ASIX packet
header may now cross URB boundaries. To handle this we have to introduce
some state between individual calls to asix_rx_fixup().
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
[ Emil: backported to 3.2:
- dropped changes to drivers/net/usb/ax88172a.c
- Introduced some static function declarations as the functions
are not used outside of asix.c (sparse is complaining about it) ]
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Eric Dumazet [Wed, 14 Mar 2012 20:18:32 +0000 (20:18 +0000)]
asix: asix_rx_fixup surgery to reduce skb truesizes
commit
a9e0aca4b37885b5599e52211f098bd7f565e749 upstream.
asix_rx_fixup() is complex, and does some unnecessary memory copies (at
least on x86 where NET_IP_ALIGN is 0)
Also, it tends to provide skbs with a big truesize (4096+256 with
MTU=1500) to upper stack, so incoming trafic consume a lot of memory and
I noticed early packet drops because we hit socket rcvbuf too fast.
Switch to a different strategy, using copybreak so that we provide nice
skbs to upper stack (including the NET_SKB_PAD to avoid future head
reallocations in some paths)
With this patch, I no longer see packets drops or tcp collapses on
various tcp workload with a AX88772 adapter.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Aurelien Jacobs <aurel@gnuage.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Trond Wuellner <trond@chromium.org>
Cc: Grant Grundler <grundler@chromium.org>
Cc: Paul Stewart <pstew@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[ Emil: Backported to 3.2: fixed small conflict ]
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Ben Hutchings [Thu, 5 Dec 2013 14:37:35 +0000 (14:37 +0000)]
deb-pkg: Fix cross-building linux-headers package
commit
f8ce239dfc7ba9add41d9ecdc5e7810738f839fa upstream.
builddeb generates a control file that says the linux-headers package
can only be built for the build system primary architecture. This
breaks cross-building configurations. We should use $debarch for this
instead.
Since $debarch is not yet set when generating the control file, set
Architecture: any and use control file variables to fill in the
description.
Fixes:
cd8d60a20a45 ('kbuild: create linux-headers package in deb-pkg')
Reported-and-tested-by: "Niew, Sh." <shniew@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Ben Hutchings [Thu, 5 Dec 2013 14:39:11 +0000 (14:39 +0000)]
deb-pkg: Fix building for MIPS big-endian or ARM OABI
commit
c5e318f67eebbad491615a752c51dbfde7dc3d78 upstream.
These commands will mysteriously fail:
$ make ARCH=arm versatile_defconfig
[...]
$ make ARCH=arm deb-pkg
[...]
make[1]: *** [deb-pkg] Error 1
make: *** [deb-pkg] Error 2
The Debian architecture selection for these kernel architectures does
'grep FOO=y $KCONFIG_CONFIG && echo bar', and after 'set -e' this
aborts the script if grep does not find the given config symbol.
Fixes:
10f26fa64200 ('build, deb-pkg: select userland architecture based on UTS_MACHINE')
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Anisse Astier [Wed, 3 Jul 2013 14:02:03 +0000 (16:02 +0200)]
deb-pkg: use KCONFIG_CONFIG instead of .config file directly
commit
d20917670ee1fd4b090555e551faea04b014ca97 upstream.
Signed-off-by: Anisse Astier <anisse@astier.eu>
Reviewed-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Michal Marek <mmarek@suse.cz>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Florian Westphal [Sat, 22 Feb 2014 09:33:26 +0000 (10:33 +0100)]
net: ip, ipv6: handle gso skbs in forwarding path
commit
fe6cc55f3a9a053482a76f5a6b2257cee51b4663 upstream.
[ use zero netdev_feature mask to avoid backport of
netif_skb_dev_features function ]
Marcelo Ricardo Leitner reported problems when the forwarding link path
has a lower mtu than the incoming one if the inbound interface supports GRO.
Given:
Host <mtu1500> R1 <mtu1200> R2
Host sends tcp stream which is routed via R1 and R2. R1 performs GRO.
In this case, the kernel will fail to send ICMP fragmentation needed
messages (or pkt too big for ipv6), as GSO packets currently bypass dstmtu
checks in forward path. Instead, Linux tries to send out packets exceeding
the mtu.
When locking route MTU on Host (i.e., no ipv4 DF bit set), R1 does
not fragment the packets when forwarding, and again tries to send out
packets exceeding R1-R2 link mtu.
This alters the forwarding dstmtu checks to take the individual gso
segment lengths into account.
For ipv6, we send out pkt too big error for gso if the individual
segments are too big.
For ipv4, we either send icmp fragmentation needed, or, if the DF bit
is not set, perform software segmentation and let the output path
create fragments when the packet is leaving the machine.
It is not 100% correct as the error message will contain the headers of
the GRO skb instead of the original/segmented one, but it seems to
work fine in my (limited) tests.
Eric Dumazet suggested to simply shrink mss via ->gso_size to avoid
sofware segmentation.
However it turns out that skb_segment() assumes skb nr_frags is related
to mss size so we would BUG there. I don't want to mess with it considering
Herbert and Eric disagree on what the correct behavior should be.
Hannes Frederic Sowa notes that when we would shrink gso_size
skb_segment would then also need to deal with the case where
SKB_MAX_FRAGS would be exceeded.
This uses sofware segmentation in the forward path when we hit ipv4
non-DF packets and the outgoing link mtu is too small. Its not perfect,
but given the lack of bug reports wrt. GRO fwd being broken this is a
rare case anyway. Also its not like this could not be improved later
once the dust settles.
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Reported-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Florian Westphal [Sat, 22 Feb 2014 09:33:25 +0000 (10:33 +0100)]
net: add and use skb_gso_transport_seglen()
commit
de960aa9ab4decc3304959f69533eef64d05d8e8 upstream.
[ no skb_gso_seglen helper in 3.4, leave tbf alone ]
This moves part of Eric Dumazets skb_gso_seglen helper from tbf sched to
skbuff core so it may be reused by upcoming ip forwarding path patch.
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Konstantin Khlebnikov [Wed, 26 Mar 2014 10:12:19 +0000 (14:12 +0400)]
ipc/msg: fix race around refcount
In older kernels (before v3.10) ipc_rcu_hdr->refcount was non-atomic int.
There was possuble double-free bug: do_msgsnd() calls ipc_rcu_putref() under
msq->q_perm->lock and RCU, while freequeue() calls it while it holds only
'rw_mutex', so there is no sinchronization between them. Two function
decrements '2' non-atomically, they both can get '0' as result.
do_msgsnd() freequeue()
msq = msg_lock_check(ns, msqid);
...
ipc_rcu_getref(msq);
msg_unlock(msq);
schedule();
(caller locks spinlock)
expunge_all(msq, -EIDRM);
ss_wakeup(&msq->q_senders, 1);
msg_rmid(ns, msq);
msg_unlock(msq);
ipc_lock_by_ptr(&msq->q_perm);
ipc_rcu_putref(msq); ipc_rcu_putref(msq);
< both may get get --(...)->refcount == 0 >
This patch locks ipc_lock and RCU around ipc_rcu_putref in freequeue.
( RCU protects memory for spin_unlock() )
Similar bugs might be in other users of ipc_rcu_putref().
In the mainline this has been fixed in v3.10 indirectly in commmit
6062a8dc0517bce23e3c2f7d2fea5e22411269a3
("ipc,sem: fine grained locking for semtimedop") by Rik van Riel.
That commit optimized locking and converted refcount into atomic.
I'm not sure that anybody should care about this bug: it's very-very unlikely
and no longer exists in actual mainline. I've found this just by looking into
the code, probably this never happens in real life.
Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Daniel Borkmann [Sun, 5 Jan 2014 23:57:54 +0000 (00:57 +0100)]
netfilter: nf_conntrack_dccp: fix skb_header_pointer API usages
commit
b22f5126a24b3b2f15448c3f2a254fc10cbc2b92 upstream.
Some occurences in the netfilter tree use skb_header_pointer() in
the following way ...
struct dccp_hdr _dh, *dh;
...
skb_header_pointer(skb, dataoff, sizeof(_dh), &dh);
... where dh itself is a pointer that is being passed as the copy
buffer. Instead, we need to use &_dh as the forth argument so that
we're copying the data into an actual buffer that sits on the stack.
Currently, we probably could overwrite memory on the stack (e.g.
with a possibly mal-formed DCCP packet), but unintentionally, as
we only want the buffer to be placed into _dh variable.
Fixes:
2bc780499aa3 ("[NETFILTER]: nf_conntrack: add DCCP protocol support")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Theodore Ts'o [Sun, 30 Mar 2014 14:20:01 +0000 (10:20 -0400)]
ext4: atomically set inode->i_flags in ext4_set_inode_flags()
commit
00a1a053ebe5febcfc2ec498bd894f035ad2aa06 upstream.
Use cmpxchg() to atomically set i_flags instead of clearing out the
S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the
EXT4_IMMUTABLE_FL, EXT4_APPEND_FL flags, since this opens up a race
where an immutable file has the immutable flag cleared for a brief
window of time.
Reported-by: John Sullivan <jsrhbz@kanargh.force9.co.uk>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Ben Hutchings [Sun, 6 Apr 2014 12:19:52 +0000 (13:19 +0100)]
staging: speakup: Prefix set_mask_bits() symbol
This is part of commit
ca2beaf84d96 ('staging: speakup: Prefix
externally-visible symbols') upstream. It is required as preparation
for commit
00a1a053ebe5 ('ext4: atomically set inode->i_flags in
ext4_set_inode_flags()').
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Hans de Goede [Fri, 28 Mar 2014 08:01:38 +0000 (01:01 -0700)]
Input: synaptics - add manual min/max quirk for ThinkPad X240
commit
8a0435d958fb36d93b8df610124a0e91e5675c82 upstream.
This extends Benjamin Tissoires manual min/max quirk table with support for
the ThinkPad X240.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Benjamin Tissoires [Fri, 28 Mar 2014 07:43:00 +0000 (00:43 -0700)]
Input: synaptics - add manual min/max quirk
commit
421e08c41fda1f0c2ff6af81a67b491389b653a5 upstream.
The new Lenovo Haswell series (-40's) contains a new Synaptics touchpad.
However, these new Synaptics devices report bad axis ranges.
Under Windows, it is not a problem because the Windows driver uses RMI4
over SMBus to talk to the device. Under Linux, we are using the PS/2
fallback interface and it occurs the reported ranges are wrong.
Of course, it would be too easy to have only one range for the whole
series, each touchpad seems to be calibrated in a different way.
We can not use SMBus to get the actual range because I suspect the firmware
will switch into the SMBus mode and stop talking through PS/2 (this is the
case for hybrid HID over I2C / PS/2 Synaptics touchpads).
So as a temporary solution (until RMI4 land into upstream), start a new
list of quirks with the min/max manually set.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Ben Hutchings [Tue, 1 Apr 2014 23:59:03 +0000 (00:59 +0100)]
Linux 3.2.56
Bjorn Helgaas [Tue, 11 Mar 2014 20:22:19 +0000 (14:22 -0600)]
PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled
commit
3cdeb713dc66057b50682048c151eae07b186c42 upstream.
Andreas reported that after
1f42db786b14 ("PCI: Enable INTx if BIOS left
them disabled"), pciehp surprise removal stopped working.
This happens because pci_reenable_device() on the hotplug bridge (used in
the pciehp_configure_device() path) clears the Interrupt Disable bit, which
apparently breaks the bridge's MSI hotplug event reporting.
Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
which is used by both pci_enable_device() and pci_reenable_device(). But
we use pci_reenable_device() after the driver may have enabled MSI or
MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.
This patch clears Interrupt Disable only when MSI/MSI-X has not been
enabled.
Fixes:
1f42db786b14 PCI: Enable INTx if BIOS left them disabled
Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691
Reported-and-tested-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Konrad Rzeszutek Wilk [Thu, 16 Aug 2012 20:06:55 +0000 (22:06 +0200)]
intel_idle: Check cpu_idle_get_driver() for NULL before dereferencing it.
commit
3735d524da64b70b41c764359da36f88aded3610 upstream.
If the machine is booted without any cpu_idle driver set
(b/c disable_cpuidle() has been called) we should follow
other users of cpu_idle API and check the return value
for NULL before using it.
Reported-and-tested-by: Mark van Dijk <mark@internecto.net>
Suggested-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Daniel Borkmann [Mon, 3 Mar 2014 16:23:04 +0000 (17:23 +0100)]
net: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is AUTH capable
[ Upstream commit
ec0223ec48a90cb605244b45f7c62de856403729 ]
RFC4895 introduced AUTH chunks for SCTP; during the SCTP
handshake RANDOM; CHUNKS; HMAC-ALGO are negotiated (CHUNKS
being optional though):
---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
<------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
-------------------- COOKIE-ECHO -------------------->
<-------------------- COOKIE-ACK ---------------------
A special case is when an endpoint requires COOKIE-ECHO
chunks to be authenticated:
---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
<------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
------------------ AUTH; COOKIE-ECHO ---------------->
<-------------------- COOKIE-ACK ---------------------
RFC4895, section 6.3. Receiving Authenticated Chunks says:
The receiver MUST use the HMAC algorithm indicated in
the HMAC Identifier field. If this algorithm was not
specified by the receiver in the HMAC-ALGO parameter in
the INIT or INIT-ACK chunk during association setup, the
AUTH chunk and all the chunks after it MUST be discarded
and an ERROR chunk SHOULD be sent with the error cause
defined in Section 4.1. [...] If no endpoint pair shared
key has been configured for that Shared Key Identifier,
all authenticated chunks MUST be silently discarded. [...]
When an endpoint requires COOKIE-ECHO chunks to be
authenticated, some special procedures have to be followed
because the reception of a COOKIE-ECHO chunk might result
in the creation of an SCTP association. If a packet arrives
containing an AUTH chunk as a first chunk, a COOKIE-ECHO
chunk as the second chunk, and possibly more chunks after
them, and the receiver does not have an STCB for that
packet, then authentication is based on the contents of
the COOKIE-ECHO chunk. In this situation, the receiver MUST
authenticate the chunks in the packet by using the RANDOM
parameters, CHUNKS parameters and HMAC_ALGO parameters
obtained from the COOKIE-ECHO chunk, and possibly a local
shared secret as inputs to the authentication procedure
specified in Section 6.3. If authentication fails, then
the packet is discarded. If the authentication is successful,
the COOKIE-ECHO and all the chunks after the COOKIE-ECHO
MUST be processed. If the receiver has an STCB, it MUST
process the AUTH chunk as described above using the STCB
from the existing association to authenticate the
COOKIE-ECHO chunk and all the chunks after it. [...]
Commit
bbd0d59809f9 introduced the possibility to receive
and verification of AUTH chunk, including the edge case for
authenticated COOKIE-ECHO. On reception of COOKIE-ECHO,
the function sctp_sf_do_5_1D_ce() handles processing,
unpacks and creates a new association if it passed sanity
checks and also tests for authentication chunks being
present. After a new association has been processed, it
invokes sctp_process_init() on the new association and
walks through the parameter list it received from the INIT
chunk. It checks SCTP_PARAM_RANDOM, SCTP_PARAM_HMAC_ALGO
and SCTP_PARAM_CHUNKS, and copies them into asoc->peer
meta data (peer_random, peer_hmacs, peer_chunks) in case
sysctl -w net.sctp.auth_enable=1 is set. If in INIT's
SCTP_PARAM_SUPPORTED_EXT parameter SCTP_CID_AUTH is set,
peer_random != NULL and peer_hmacs != NULL the peer is to be
assumed asoc->peer.auth_capable=1, in any other case
asoc->peer.auth_capable=0.
Now, if in sctp_sf_do_5_1D_ce() chunk->auth_chunk is
available, we set up a fake auth chunk and pass that on to
sctp_sf_authenticate(), which at latest in
sctp_auth_calculate_hmac() reliably dereferences a NULL pointer
at position 0..0008 when setting up the crypto key in
crypto_hash_setkey() by using asoc->asoc_shared_key that is
NULL as condition key_id == asoc->active_key_id is true if
the AUTH chunk was injected correctly from remote. This
happens no matter what net.sctp.auth_enable sysctl says.
The fix is to check for net->sctp.auth_enable and for
asoc->peer.auth_capable before doing any operations like
sctp_sf_authenticate() as no key is activated in
sctp_auth_asoc_init_active_key() for each case.
Now as RFC4895 section 6.3 states that if the used HMAC-ALGO
passed from the INIT chunk was not used in the AUTH chunk, we
SHOULD send an error; however in this case it would be better
to just silently discard such a maliciously prepared handshake
as we didn't even receive a parameter at all. Also, as our
endpoint has no shared key configured, section 6.3 says that
MUST silently discard, which we are doing from now onwards.
Before calling sctp_sf_pdiscard(), we need not only to free
the association, but also the chunk->auth_chunk skb, as
commit
bbd0d59809f9 created a skb clone in that case.
I have tested this locally by using netfilter's nfqueue and
re-injecting packets into the local stack after maliciously
modifying the INIT chunk (removing RANDOM; HMAC-ALGO param)
and the SCTP packet containing the COOKIE_ECHO (injecting
AUTH chunk before COOKIE_ECHO). Fixed with this patch applied.
Fixes:
bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Vlad Yasevich <yasevich@gmail.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Michael Chan [Fri, 28 Feb 2014 23:05:10 +0000 (15:05 -0800)]
tg3: Don't check undefined error bits in RXBD
[ Upstream commit
d7b95315cc7f441418845a165ee56df723941487 ]
Redefine the RXD_ERR_MASK to include only relevant error bits. This fixes
a customer reported issue of randomly dropping packets on the 5719.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jason Wang [Fri, 21 Feb 2014 05:08:04 +0000 (13:08 +0800)]
virtio-net: alloc big buffers also when guest can receive UFO
[ Upstream commit
0e7ede80d929ff0f830c44a543daa1acd590c749 ]
We should alloc big buffers also when guest can receive UFO
packets to let the big packets fit into guest rx buffer.
Fixes
5c5167515d80f78f6bb538492c423adcae31ad65
(virtio-net: Allow UFO feature to be set and advertised.)
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Paul E. McKenney [Sat, 27 Jul 2013 10:53:54 +0000 (03:53 -0700)]
jiffies: Avoid undefined behavior from signed overflow
commit
5a581b367b5df0531265311fc681c2abd377e5e6 upstream.
According to the C standard 3.4.3p3, overflow of a signed integer results
in undefined behavior. This commit therefore changes the definitions
of time_after(), time_after_eq(), time_after64(), and time_after_eq64()
to avoid this undefined behavior. The trick is that the subtraction
is done using unsigned arithmetic, which according to 6.2.5p9 cannot
overflow because it is defined as modulo arithmetic. This has the added
(though admittedly quite small) benefit of shortening four lines of code
by four characters each.
Note that the C standard considers the cast from unsigned to
signed to be implementation-defined, see 6.3.1.3p3. However, on a
two's-complement system, an implementation that defines anything other
than a reinterpretation of the bits is free to come to me, and I will be
happy to act as a witness for its being committed to an insane asylum.
(Although I have nothing against saturating arithmetic or signals in some
cases, these things really should not be the default when compiling an
operating-system kernel.)
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Kevin Easton <kevin@guarana.org>
[ paulmck: Included time_after64() and time_after_eq64(), as suggested
by Eric Dumazet, also fixed commit message.]
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Clemens Ladisch [Wed, 5 Mar 2014 21:16:17 +0000 (22:16 +0100)]
ALSA: oxygen: Xonar DG(X): modify DAC routing
commit
1f91ecc14deea9461aca93273d78871ec4d98fcd upstream.
When selecting the audio output destinations (headphones, FP headphones,
multichannel output), unnecessary I2S channels are digitally muted to
avoid invalid signal levels on the other outputs.
Signed-off-by: Roman Volkov <v1ron@mail.ru>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Roman Volkov [Fri, 24 Jan 2014 12:18:14 +0000 (16:18 +0400)]
ALSA: oxygen: Xonar DG(X): capture from I2S channel 1, not 2
commit
3dd77654fb1d7f68b9739f3039bad8dbbc0739f8 upstream.
Actually CS4245 connected to the I2S channel 1 for
capture, not channel 2. Otherwise capturing and
playback does not work for CS4245.
Signed-off-by: Roman Volkov <v1ron@mail.ru>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Takashi Iwai [Thu, 11 Jul 2013 16:00:59 +0000 (18:00 +0200)]
saa7134: Fix unlocked snd_pcm_stop() call
commit
e6355ad7b1c6f70e2f48ae159f5658b441ccff95 upstream.
snd_pcm_stop() must be called in the PCM substream lock context.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[wml: Backported to 3.4: Adjust filename]
Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Martijn de Gouw [Wed, 24 Oct 2012 09:45:46 +0000 (11:45 +0200)]
cifs: set MAY_SIGN when sec=krb5
commit
0b7bc84000d71f3647ca33ab1bf5bd928535c846 upstream.
Setting this secFlg allows usage of dfs where some servers require
signing and others don't.
Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive.nl>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
[Joseph Salisbury: This backport was done so including mainline commit
8830d7e07a5e38bc47650a7554b7c1cfd49902bf is not needed.]
BugLink: http://bugs.launchpad.net/bugs/1285723
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Daniel Borkmann [Mon, 17 Feb 2014 11:11:11 +0000 (12:11 +0100)]
net: sctp: fix sctp_connectx abi for ia32 emulation/compat mode
[ Upstream commit
ffd5939381c609056b33b7585fb05a77b4c695f3 ]
SCTP's sctp_connectx() abi breaks for 64bit kernels compiled with 32bit
emulation (e.g. ia32 emulation or x86_x32). Due to internal usage of
'struct sctp_getaddrs_old' which includes a struct sockaddr pointer,
sizeof(param) check will always fail in kernel as the structure in
64bit kernel space is 4bytes larger than for user binaries compiled
in 32bit mode. Thus, applications making use of sctp_connectx() won't
be able to run under such circumstances.
Introduce a compat interface in the kernel to deal with such
situations by using a 'struct compat_sctp_getaddrs_old' structure
where user data is copied into it, and then sucessively transformed
into a 'struct sctp_getaddrs_old' structure with the help of
compat_ptr(). That fixes sctp_connectx() abi without any changes
needed in user space, and lets the SCTP test suite pass when compiled
in 32bit and run on 64bit kernels.
Fixes:
f9c67811ebc0 ("sctp: Fix regression introduced by new sctp_connectx api")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jiri Bohac [Fri, 14 Feb 2014 17:13:50 +0000 (18:13 +0100)]
bonding: 802.3ad: make aggregator_identifier bond-private
[ Upstream commit
163c8ff30dbe473abfbb24a7eac5536c87f3baa9 ]
aggregator_identifier is used to assign unique aggregator identifiers
to aggregators of a bond during device enslaving.
aggregator_identifier is currently a global variable that is zeroed in
bond_3ad_initialize().
This sequence will lead to duplicate aggregator identifiers for eth1 and eth3:
create bond0
change bond0 mode to 802.3ad
enslave eth0 to bond0 //eth0 gets agg id 1
enslave eth1 to bond0 //eth1 gets agg id 2
create bond1
change bond1 mode to 802.3ad
enslave eth2 to bond1 //aggregator_identifier is reset to 0
//eth2 gets agg id 1
enslave eth3 to bond0 //eth3 gets agg id 2
Fix this by making aggregator_identifier private to the bond.
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Acked-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Emil Goode [Thu, 13 Feb 2014 16:50:19 +0000 (17:50 +0100)]
usbnet: remove generic hard_header_len check
[ Upstream commit
eb85569fe2d06c2fbf4de7b66c263ca095b397aa ]
This patch removes a generic hard_header_len check from the usbnet
module that is causing dropped packages under certain circumstances
for devices that send rx packets that cross urb boundaries.
One example is the AX88772B which occasionally send rx packets that
cross urb boundaries where the remaining partial packet is sent with
no hardware header. When the buffer with a partial packet is of less
number of octets than the value of hard_header_len the buffer is
discarded by the usbnet module.
With AX88772B this can be reproduced by using ping with a packet
size between 1965-1976.
The bug has been reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=29082
This patch introduces the following changes:
- Removes the generic hard_header_len check in the rx_complete
function in the usbnet module.
- Introduces a ETH_HLEN check for skbs that are not cloned from
within a rx_fixup callback.
- For safety a hard_header_len check is added to each rx_fixup
callback function that could be affected by this change.
These extra checks could possibly be removed by someone
who has the hardware to test.
- Removes a call to dev_kfree_skb_any() and instead utilizes the
dev->done list to queue skbs for cleanup.
The changes place full responsibility on the rx_fixup callback
functions that clone skbs to only pass valid skbs to the
usbnet_skb_return function.
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Reported-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Nithin Sujir [Thu, 6 Feb 2014 22:13:05 +0000 (14:13 -0800)]
tg3: Fix deadlock in tg3_change_mtu()
[ Upstream commit
c6993dfd7db9b0c6b7ca7503a56fda9236a4710f ]
Quoting David Vrabel -
"5780 cards cannot have jumbo frames and TSO enabled together. When
jumbo frames are enabled by setting the MTU, the TSO feature must be
cleared. This is done indirectly by calling netdev_update_features()
which will call tg3_fix_features() to actually clear the flags.
netdev_update_features() will also trigger a new netlink message for the
feature change event which will result in a call to tg3_get_stats64()
which deadlocks on the tg3 lock."
tg3_set_mtu() does not need to be under the tg3 lock since converting
the flags to use set_bit(). Move it out to after tg3_netif_stop().
Reported-by: David Vrabel <david.vrabel@citrix.com>
Tested-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Maciej Żenczykowski [Sat, 8 Feb 2014 00:23:48 +0000 (16:23 -0800)]
net: fix 'ip rule' iif/oif device rename
[ Upstream commit
946c032e5a53992ea45e062ecb08670ba39b99e3 ]
ip rules with iif/oif references do not update:
(detach/attach) across interface renames.
Signed-off-by: Maciej Żenczykowski <maze@google.com>
CC: Willem de Bruijn <willemb@google.com>
CC: Eric Dumazet <edumazet@google.com>
CC: Chris Davis <chrismd@google.com>
CC: Carlo Contavalli <ccontavalli@google.com>
Google-Bug-Id:
12936021
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Paul E. McKenney [Tue, 16 Oct 2012 04:35:59 +0000 (21:35 -0700)]
printk: Fix scheduling-while-atomic problem in console_cpu_notify()
commit
85eae82a0855d49852b87deac8653e4ebc8b291f upstream.
The console_cpu_notify() function runs with interrupts disabled in the
CPU_DYING case. It therefore cannot block, for example, as will happen
when it calls console_lock(). Therefore, remove the CPU_DYING leg of
the switch statement to avoid this problem.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Colin Cross [Mon, 10 Feb 2014 21:16:29 +0000 (13:16 -0800)]
timekeeping: fix 32-bit overflow in get_monotonic_boottime
fixed upstream in v3.6 by
ec145babe754f9ea1079034a108104b6001e001c
get_monotonic_boottime adds three nanonsecond values stored
in longs, followed by an s64. If the long values are all
close to 1e9 the first three additions can overflow and
become negative when added to the s64. Cast the first
value to s64 so that all additions are 64 bit.
Signed-off-by: Colin Cross <ccross@android.com>
[jstultz: Fished this out of the AOSP commong.git tree. This was
fixed upstream in v3.6 by
ec145babe754f9ea1079034a108104b6001e001c]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Steven Rostedt [Tue, 11 Feb 2014 19:50:01 +0000 (14:50 -0500)]
ftrace: Have function graph only trace based on global_ops filters
commit
23a8e8441a0a74dd612edf81dc89d1600bc0a3d1 upstream.
Doing some different tests, I discovered that function graph tracing, when
filtered via the set_ftrace_filter and set_ftrace_notrace files, does
not always keep with them if another function ftrace_ops is registered
to trace functions.
The reason is that function graph just happens to trace all functions
that the function tracer enables. When there was only one user of
function tracing, the function graph tracer did not need to worry about
being called by functions that it did not want to trace. But now that there
are other users, this becomes a problem.
For example, one just needs to do the following:
# cd /sys/kernel/debug/tracing
# echo schedule > set_ftrace_filter
# echo function_graph > current_tracer
# cat trace
[..]
0) | schedule() {
------------------------------------------
0) <idle>-0 => rcu_pre-7
------------------------------------------
0) ! 2980.314 us | }
0) | schedule() {
------------------------------------------
0) rcu_pre-7 => <idle>-0
------------------------------------------
0) + 20.701 us | }
# echo 1 > /proc/sys/kernel/stack_tracer_enabled
# cat trace
[..]
1) + 20.825 us | }
1) + 21.651 us | }
1) + 30.924 us | } /* SyS_ioctl */
1) | do_page_fault() {
1) | __do_page_fault() {
1) 0.274 us | down_read_trylock();
1) 0.098 us | find_vma();
1) | handle_mm_fault() {
1) | _raw_spin_lock() {
1) 0.102 us | preempt_count_add();
1) 0.097 us | do_raw_spin_lock();
1) 2.173 us | }
1) | do_wp_page() {
1) 0.079 us | vm_normal_page();
1) 0.086 us | reuse_swap_page();
1) 0.076 us | page_move_anon_rmap();
1) | unlock_page() {
1) 0.082 us | page_waitqueue();
1) 0.086 us | __wake_up_bit();
1) 1.801 us | }
1) 0.075 us | ptep_set_access_flags();
1) | _raw_spin_unlock() {
1) 0.098 us | do_raw_spin_unlock();
1) 0.105 us | preempt_count_sub();
1) 1.884 us | }
1) 9.149 us | }
1) + 13.083 us | }
1) 0.146 us | up_read();
When the stack tracer was enabled, it enabled all functions to be traced, which
now the function graph tracer also traces. This is a side effect that should
not occur.
To fix this a test is added when the function tracing is changed, as well as when
the graph tracer is enabled, to see if anything other than the ftrace global_ops
function tracer is enabled. If so, then the graph tracer calls a test trampoline
that will look at the function that is being traced and compare it with the
filters defined by the global_ops.
As an optimization, if there's no other function tracers registered, or if
the only registered function tracers also use the global ops, the function
graph infrastructure will call the registered function graph callback directly
and not go through the test trampoline.
Fixes:
d2d45c7a03a2 "tracing: Have stack_tracer use a separate list of functions"
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Al Viro [Sat, 18 May 2013 06:38:52 +0000 (02:38 -0400)]
hpfs: deadlock and race in directory lseek()
commit
31abdab9c11bb1694ecd1476a7edbe8e964d94ac upstream.
For one thing, there's an ABBA deadlock on hpfs fs-wide lock and i_mutex
in hpfs_dir_lseek() - there's a lot of methods that grab the former with
the caller already holding the latter, so it must take i_mutex first.
For another, locking the damn thing, carefully validating the offset,
then dropping locks and assigning the offset is obviously racy.
Moreover, we _must_ do hpfs_add_pos(), or the machinery in dnode.c
won't modify the sucker on B-tree surgeries.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Mikulas Patocka [Tue, 28 Jan 2014 23:10:44 +0000 (00:10 +0100)]
hpfs: remember free space
commit
2cbe5c76fc5e38e9af4b709593146e4b8272b69e upstream.
Previously, hpfs scanned all bitmaps each time the user asked for free
space using statfs. This patch changes it so that hpfs scans the
bitmaps only once, remembes the free space and on next invocation of
statfs it returns the value instantly.
New versions of wine are hammering on the statfs syscall very heavily,
making some games unplayable when they're stored on hpfs, with load
times in minutes.
This should be backported to the stable kernels because it fixes
user-visible problem (excessive level load times in wine).
Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[ kamal: backport to 3.8 (no hpfs_prefetch_bitmap) ]
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Geert Uytterhoeven [Fri, 22 Nov 2013 15:47:26 +0000 (16:47 +0100)]
TTY: pmac_zilog, check existence of ports in pmz_console_init()
commit
dc1dc2f8a5dd863bf2e79f338fc3ae29e99c683a upstream.
When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0"
on the kernel command line, it crashes with:
Unable to handle kernel NULL pointer dereference at virtual address (null)
Oops:
00000000
PC: [<
0013ad28>] __pmz_startup+0x32/0x2a0
...
Call Trace: [<
002c5d3e>] pmz_console_setup+0x64/0xe4
The normal tty driver doesn't crash, because init_pmz() checks
pmz_ports_count again after calling pmz_probe().
In the serial console initialization path, pmz_console_init() doesn't do
this, causing the driver to crash later.
Add a check for pmz_ports_count to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Finn Thain <fthain@telegraphics.com.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jianguo Wu [Thu, 19 Dec 2013 01:08:59 +0000 (17:08 -0800)]
mm/hugetlb: check for pte NULL pointer in __page_check_address()
commit
98398c32f6687ee1e1f3ae084effb4b75adb0747 upstream.
In __page_check_address(), if address's pud is not present,
huge_pte_offset() will return NULL, we should check the return value.
Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: qiuxishi <qiuxishi@huawei.com>
Cc: Hanjun Guo <guohanjun@huawei.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Helge Deller [Mon, 2 Dec 2013 18:59:31 +0000 (19:59 +0100)]
nfs: fix do_div() warning by instead using sector_div()
commit
3873d064b8538686bbbd4b858dc8a07db1f7f43a upstream.
When compiling a 32bit kernel with CONFIG_LBDAF=n the compiler complains like
shown below. Fix this warning by instead using sector_div() which is provided
by the kernel.h header file.
fs/nfs/blocklayout/extents.c: In function ‘normalize’:
include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer types lacks a cast [enabled by default]
fs/nfs/blocklayout/extents.c:47:13: note: in expansion of macro ‘do_div’
nfs/blocklayout/extents.c:47:2: warning: right shift count >= width of type [enabled by default]
fs/nfs/blocklayout/extents.c:47:2: warning: passing argument 1 of ‘__div64_32’ from incompatible pointer type [enabled by default]
include/asm-generic/div64.h:35:17: note: expected ‘uint64_t *’ but argument is of type ‘sector_t *’
extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Ian Abbott [Tue, 20 Aug 2013 10:50:19 +0000 (11:50 +0100)]
staging: comedi: pcmuio: fix possible NULL deref on detach
commit
2fd2bdfccae61efe18f6b92b6a45fbf936d75b48 upstream.
pcmuio_detach() is called by the comedi core even if pcmuio_attach()
returned an error, so `dev->private` might be `NULL`. Check for that
before dereferencing it.
Also, as pointed out by Dan Carpenter, there is no need to check the
pointer passed to `kfree()` is non-NULL, so remove that check.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Ian Abbott [Thu, 12 Dec 2013 11:32:19 +0000 (11:32 +0000)]
staging: comedi: ssv_dnp: correct insn_bits result
[Part of commit
f6b316bcd8c421acd6fa5a6e18b4c846ecb9d965 upstream.
Split from original patch subject: "staging: comedi: ssv_dnp: use
comedi_dio_update_state()"]
Also, fix a bug where the state of the channels is returned in data[0].
The comedi core expects it to be returned in data[1].
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Daniel J Blueman [Thu, 13 Mar 2014 11:43:01 +0000 (19:43 +0800)]
x86/amd/numa: Fix northbridge quirk to assign correct NUMA node
commit
847d7970defb45540735b3fb4e88471c27cacd85 upstream.
For systems with multiple servers and routed fabric, all
northbridges get assigned to the first server. Fix this by also
using the node reported from the PCI bus. For single-fabric
systems, the northbriges are on PCI bus 0 by definition, which
are on NUMA node 0 by definition, so this is invarient on most
systems.
Tested on fam10h and fam15h single and multi-fabric systems and
candidate for stable.
Signed-off-by: Daniel J Blueman <daniel@numascale.com>
Acked-by: Steffen Persvold <sp@numascale.com>
Acked-by: Borislav Petkov <bp@suse.de>
Link: http://lkml.kernel.org/r/1394710981-3596-1-git-send-email-daniel@numascale.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Arnd Bergmann [Thu, 13 Mar 2014 09:44:34 +0000 (10:44 +0100)]
vmxnet3: fix building without CONFIG_PCI_MSI
commit
0a8d8c446b5429d15ff2d48f46e00d8a08552303 upstream.
Since commit
d25f06ea466e "vmxnet3: fix netpoll race condition",
the vmxnet3 driver fails to build when CONFIG_PCI_MSI is disabled,
because it unconditionally references the vmxnet3_msix_rx()
function.
To fix this, use the same #ifdef in the caller that exists around
the function definition.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Shreyas Bhatewara <sbhatewara@vmware.com>
Cc: "VMware, Inc." <pv-drivers@vmware.com>
Cc: "David S. Miller" <davem@davemloft.net>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Radim Krčmář [Tue, 11 Mar 2014 18:11:18 +0000 (19:11 +0100)]
KVM: SVM: fix cr8 intercept window
commit
596f3142d2b7be307a1652d59e7b93adab918437 upstream.
We always disable cr8 intercept in its handler, but only re-enable it
if handling KVM_REQ_EVENT, so there can be a window where we do not
intercept cr8 writes, which allows an interrupt to disrupt a higher
priority task.
Fix this by disabling intercepts in the same function that re-enables
them when needed. This fixes BSOD in Windows 2008.
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Neil Horman [Mon, 10 Mar 2014 10:55:55 +0000 (06:55 -0400)]
vmxnet3: fix netpoll race condition
commit
d25f06ea466ea521b563b76661180b4e44714ae6 upstream.
vmxnet3's netpoll driver is incorrectly coded. It directly calls
vmxnet3_do_poll, which is the driver internal napi poll routine. As the netpoll
controller method doesn't block real napi polls in any way, there is a potential
for race conditions in which the netpoll controller method and the napi poll
method run concurrently. The result is data corruption causing panics such as this
one recently observed:
PID: 1371 TASK:
ffff88023762caa0 CPU: 1 COMMAND: "rs:main Q:Reg"
#0 [
ffff88023abd5780] machine_kexec at
ffffffff81038f3b
#1 [
ffff88023abd57e0] crash_kexec at
ffffffff810c5d92
#2 [
ffff88023abd58b0] oops_end at
ffffffff8152b570
#3 [
ffff88023abd58e0] die at
ffffffff81010e0b
#4 [
ffff88023abd5910] do_trap at
ffffffff8152add4
#5 [
ffff88023abd5970] do_invalid_op at
ffffffff8100cf95
#6 [
ffff88023abd5a10] invalid_op at
ffffffff8100bf9b
[exception RIP: vmxnet3_rq_rx_complete+1968]
RIP:
ffffffffa00f1e80 RSP:
ffff88023abd5ac8 RFLAGS:
00010086
RAX:
0000000000000000 RBX:
ffff88023b5dcee0 RCX:
00000000000000c0
RDX:
0000000000000000 RSI:
00000000000005f2 RDI:
ffff88023b5dcee0
RBP:
ffff88023abd5b48 R8:
0000000000000000 R9:
ffff88023a3b6048
R10:
0000000000000000 R11:
0000000000000002 R12:
ffff8802398d4cd8
R13:
ffff88023af35140 R14:
ffff88023b60c890 R15:
0000000000000000
ORIG_RAX:
ffffffffffffffff CS: 0010 SS: 0018
#7 [
ffff88023abd5b50] vmxnet3_do_poll at
ffffffffa00f204a [vmxnet3]
#8 [
ffff88023abd5b80] vmxnet3_netpoll at
ffffffffa00f209c [vmxnet3]
#9 [
ffff88023abd5ba0] netpoll_poll_dev at
ffffffff81472bb7
The fix is to do as other drivers do, and have the poll controller call the top
half interrupt handler, which schedules a napi poll properly to recieve frames
Tested by myself, successfully.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Shreyas Bhatewara <sbhatewara@vmware.com>
CC: "VMware, Inc." <pv-drivers@vmware.com>
CC: "David S. Miller" <davem@davemloft.net>
Reviewed-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
git.openpandora.org / pandora-kernel.git / log