RTT may be bogus with tall loss probe (TLP) when a packet
is retransmitted and latter (s)acked without TCPCB_SACKED_RETRANS flag.
For example, TLP calls __tcp_retransmit_skb() instead of
tcp_retransmit_skb(). The skb timestamps are updated but the sacked
flag is not marked with TCPCB_SACKED_RETRANS. As a result we'll
get bogus RTT in tcp_clean_rtx_queue() or in tcp_sacktag_one() on
spurious retransmission.
The fix is to apply the sticky flag TCP_EVER_RETRANS to enforce Karn's
check on RTT sampling. However this will disable F-RTO if timeout occurs
after TLP, by resetting undo_marker in tcp_enter_loss(). We relax this
check to only if any pending retransmists are still in-flight.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is a sanity check and we never pass invalid values so this patch
doesn't change anything. However the node->time_in[] array has
HSR_MAX_SLAVE (2) elements and not HSR_MAX_DEV (3).
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull scheduler fixes from Ingo Molnar:
"Misc fixes, most of them SCHED_DEADLINE fallout"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/deadline: Prevent rt_time growth to infinity
sched/deadline: Switch CPU's presence test order
sched/deadline: Cleanup RT leftovers from {inc/dec}_dl_migration
sched: Fix double normalization of vruntime
Pull liblockdep fixes from Ingo Molnar:
"A handful of build fixes for liblockdep"
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tools/liblockdep: Use realpath for srctree and objtree
tools/liblockdep: Add a stub for new rcu_is_watching
tools/liblockdep: Mark runtests.sh as executable
tools/liblockdep: Add include directory to allow tests to compile
tools/liblockdep: Fix include of asm/hash.h
tools/liblockdep: Fix initialization code path
regressions. There is a single framework fix that prevents dereferencing
a NULL pointer when calling clk_get. The range of fixes for clock driver
regressions spans memory leak fixes, touching the wrong registers that
cause things to explode, misconfigured clock rates that result in
non-responsive devices and even some boot failures. The most benign fix
is DT binding doc typo. It is a stable ABI exposed from the kernel that
was introduced in -rc1, so best to fix it now.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJTEpHGAAoJEDqPOy9afJhJBHUP/3rkQWvFA216EO8zhIQMnJS/
Xw6S+jufccG2u4arJsVUTJ2n3Xak0J/LNU2MYRHrIc+xLgk5KdntmcmQ2qcEeh46
YOp9UYx1qACy4FtFG6yjZibmD6sZ9YWJrEn58xeBUXZck3aoV8MDblMmY5xZu0wM
EOI8HD/RNmLe8SwXfJglmlsUuv5n5IOSw73Dqkjj5J4/mGUh2BqvItDJPfnt23fI
EgURLYRTnQ8xBYfvV0F+8HOFUqYegRuJO9P9/ykfdzSaJZD+96jnImaaeOr34z7d
xL/HXQEkK/kft5iF70Hnhcb24j/JVdrC22+TZi16YwIODLeCyaIHBO/UsZ/0f5rY
MHz1Y4m8ZWnH3RCvfFJ2VJqAzb5UmKbRGS6Sg8SBdx4icBSvvWudIHeql4StTGZ3
Hgi2WkJeLO+PCwbpECNtDdhtPZV6H3r+AFyllcEx+V8AK0U25vOhOg+2ijJSPrW7
1gLQX+Yyco+zjcV2umGw/l3pfm/JjpE2IfJxtgMS2C84+/kGGgppPHiZPQzowpKT
ClPTziZjkzFP4ZE1fCEWGidCyqyjKr69TasIA0gxhI6h4aVvr5sRGhfgtEfMrbE9
dLFoMeQ7EMmZdMRX0O9IJuXt79yPs4Z5v9oX32C18Qyz7I04E6UBuueRgMJCglZP
3NoIkEbGeHQdD6YpihEQ
=zck4
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux
Pull clk framework fixes from Mike Turquette:
"Clock framework and driver fixes, all of which fix user-visible
regressions.
There is a single framework fix that prevents dereferencing a NULL
pointer when calling clk_get. The range of fixes for clock driver
regressions spans memory leak fixes, touching the wrong registers that
cause things to explode, misconfigured clock rates that result in
non-responsive devices and even some boot failures. The most benign
fix is DT binding doc typo. It is a stable ABI exposed from the
kernel that was introduced in -rc1, so best to fix it now"
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux: (25 commits)
clk:at91: Fix memory leak in of_at91_clk_master_setup()
clk: nomadik: fix multiplatform problem
clk: Correct handling of NULL clk in __clk_{get, put}
clk: shmobile: Fix typo in MSTP clock DT bindings
clk: shmobile: rcar-gen2: Fix qspi divisor
clk: shmobile: rcar-gen2: Fix clock parent for all non-PLL clocks
clk: tegra124: remove gr2d and gr3d clocks
clk: tegra: Fix vic03 mux index
clk: shmobile: rcar-gen2: Fix qspi divisor
clk: shmobile: rcar-gen2: Fix clock parent all non-PLL clocks
clk: tegra: use max divider if divider overflows
clk: tegra: cclk_lp has a pllx/2 divider
clk: tegra: fix sdmmc clks on Tegra1x4
clk: tegra: fix host1x clock on Tegra124
clk: tegra: PLLD2 fixes for hdmi
clk: tegra: Fix PLLD mnp table
clk: tegra: Fix PLLP rate table
clk: tegra: Correct clock number for UARTE
clk: tegra: Add missing Tegra20 fuse clks
ARM: keystone: dts: fix clkvcp3 control register address
...
Working with HDMI TVs is a real pain as they tend to overscan by
default, meaning that the pixels around the edge of the framebuffer
are not displayed. This is well explained here:
http://mjg59.dreamwidth.org/8705.html
There is a bit in the HDMI info frame that can request that the
remote display shows the full pixel data ("underscan"). For the
remote display, the HDMI spec states that this is optional - it
doesn't have to listen. That means that most TVs will probably ignore
this.
But, maybe there are a handful of TVs for which this would help
the situation. As we live in a digital world, ask the remote
display not to overscan by default.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The kfifo_put() API changed in 498d319bb5 (kfifo API type safety)
which now results in the wrong pointer being added to the kfifo ring,
which then causes an oops. Fix this.
Cc: <stable@vger.kernel.org> # 3.13
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Single-link DVI max dotclock is 165MHz. Filter out modes with higher
dotclock when the monitor doesn't support HDMI.
Modes higher than 165 MHz were allowed in
commit 7d148ef51a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Jul 22 18:02:39 2013 +0200
drm/i915: fix hdmi portclock limits
Also don't attempt to use 12bpc mode with DVI monitors.
Cc: Adam Nielsen <a.nielsen@shikadi.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75345
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70331
Tested-by: Ralf Jung <post+kernel@ralfj.de>
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We need to read the correct register, not a register that doesn't exist
and will trigger "Unclaimed register" messages when we touch it.
Also rearrange the checks in an attempt to prevent this error from
happening again.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[Jani: dropped an extra empty line introduced.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We reserve the space for the power context in stolen memory at a fixed
address from a delayed work. This races with the subsequent driver
init/resume code which could allocate something at that address, so the
reservation for the power context fails. Reserve the space up-front, so
this can't happen. This also adds a missing struct_mutex lock around the
stolen allocation, which wasn't taken in the delayed work path.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This patch does a cleanup about the thermal zone govenor,
setting and make the following rule.
1. For thermal zone devices that are registered w/o tz->tzp,
they can use the default thermal governor only.
2. For thermal zone devices w/ governor name specified in
tz->tzp->governor_name, we will use the default govenor
if the governor specified is not available at the moment,
and update tz->governor when the matched governor is registered.
This also fixes a problem that OF registered thermal zones
are running with no governor.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Javi Merino <javi.merino@arm.com>
In initialization, if the cooling device is initialized at
max cooling state, and the thermal zone temperature is below
the first trip point, then the cooling state can't be updated
to the right state, untill the first trip point be triggered.
To fix this issue, allow first update of cooling device state
during registration, initialized "updated" device field as
"false" (instead of "true").
Signed-off-by: Wei Ni <wni@nvidia.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Commit beeb5a1e (thermal: rcar-thermal: Enable driver compilation with COMPILE_TEST)
broke build on archs wihout io memory.
On archs like S390 or um this driver cannot build nor work.
Make it depend on HAS_IOMEM to bypass build failures.
drivers/thermal/rcar_thermal.c:404: undefined reference to `devm_ioremap_resource'
drivers/thermal/rcar_thermal.c:426: undefined reference to `devm_ioremap_resource'
Signed-off-by: Richard Weinberger <richard@nod.at>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The thermal zone type should not include an instance number. Otherwise
each zone is considered a different type and the thermal-to-hwmon
bridge fails to group them all in a single hwmon device.
I also changed the type to "x86_pkg_temp", because "pkg" was too
generic, and other thermal drivers use an underscore, not a dash, as
a separator. Or maybe "cpu_pkg_temp" would be better?
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The temperature value reported by x86_pkg_temp_thermal is already
reported by the coretemp driver. So, do not expose this thermal zone
as a hwmon device, because it would be redundant.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <eduardo.valentin@ti.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
arch/arm/xen/enlighten.c (and maybe others) use MMU-specific functions
like pte_mkspecial which are only available on MMU builds. So let XEN
depend on MMU.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In commit e2d265d3b5 (canfd: add support for CAN FD in CAN_RAW sockets)
CAN FD frames with a payload length up to 8 byte are passed to legacy
sockets where the CAN FD support was not enabled by the application.
After some discussions with developers at a fair this well meant feature
leads to confusion as no clean switch for CAN / CAN FD is provided to the
application programmer. Additionally a compatibility like this for legacy
CAN_RAW sockets requires some compatibility handling for the sending, e.g.
make CAN2.0 frames a CAN FD frame with BRS at transmission time (?!?).
This will become a mess when people start to develop applications with
real CAN FD hardware. This patch reverts the bad compatibility code
together with the documentation describing the removed feature.
Acked-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This patch adds the missing netif_napi_del() to the flexcan_remove() function.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
In case of AP mode, the beacon interval is already reset to
zero inside cfg80211_stop_ap(), and in the other modes it
isn't relevant. Remove the assignment to remove a potential
race since the assignment isn't properly locked.
Reported-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When calculating the current max bw required for
a channel context, we didn't consider the virtual
monitor interface, resulting in its channel context
being narrower than configured.
This broke monitor mode with iwlmvm, which uses the
minimal width.
Reported-by: Ido Yariv <idox.yariv@intel.com>
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This patch factors out freeze and unfreeze of the CAN core into seperate
functions. Experiments have shown that the transition from and to freeze mode
may take several microseconds, especially the time entering the freeze mode
depends on the current bitrate.
This patch adds a while loop which polls the Freeze Mode ACK bit (FRZ_ACK) that
indicates a successfull mode change. If the function runs into a timeout a
error value is returned.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This patch moves the transceiver enable and disable into seperate functions,
where the NULL pointer check is hidden.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
In flexcan_chip_enable() and flexcan_chip_disable() fixed delays are used.
Experiments have shown that the transition from and to low power mode may take
several microseconds.
This patch adds a while loop which polls the Low Power Mode ACK bit (LPM_ACK)
that indicates a successfull mode change. If the function runs into a timeout a
error value is returned.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
If flexcan_chip_start() in flexcan_open() fails, the interrupt is not freed,
this patch adds the missing cleanup.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
When shutting down the CAN interface (ifconfig canX down) during high CAN bus
loads, the CAN core might hang and freeze the whole CPU.
This patch fixes the shutdown sequence by first disabling the CAN core then
disabling all interrupts.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
No need to make it more complicated than necessary,
just allocate the page tables as normal BO and
flush whenever the address change.
v2: update comments and function name
v3: squash bug fixes, page directory and tables patch
v4: rebased on Mareks changes
Signed-off-by: Christian König <christian.koenig@amd.com>
Userspace should set the first 4 bits of drm_radeon_cs_reloc::flags to
a number from 0 to 15. The higher the number, the higher the priority,
which means a buffer with a higher number will be validated sooner.
The old behavior is preserved: Buffers used for write are prioritized over
read-only buffers if the userspace doesn't set the number.
v2: add buffers to buckets directly, then concatenate them
v3: use a stable sort
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
The statistics are:
- VRAM usage in bytes
- GTT usage in bytes
- number of bytes moved by TTM
The last one is actually a counter, so you need to sample it before and after
command submission and take the difference.
This is useful for finding performance bottlenecks. Userspace queries are
also added.
v2: use atomic64_t
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
When passing buffers between processes, the receiving process needs to know
the original buffer domain, so that it doesn't accidentally move the buffer.
v2: reserve the buffer
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
There is a conflict seen when requesting the kernel to reserve
the physical space used for the stolen area. This is because
some BIOS are wrapping the stolen area in the root PCI bus, but have
an off-by-one error. As a workaround we retry the reservation with an
offset of 1 instead of 0.
v2: updated commit message & the comment in source file (Daniel)
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
i915gm and i945gm also seem to use and need the legacy combination mode
bit in BLC_PWM_CTL.
v2: Also do this for i915gm (Ville).
Reported-and-tested-by: Luis Ortega <luiorpe1@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75001
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The 'ath79_spi_setup_cs' function initializes the chip
select line of a given SPI device in order to make sure
that the device is inactive.
If the SPI_CS_HIGH bit is set for a given device, it
means that the CS line of that device is active HIGH
so it must be set to LOW initially. In case of GPIO
CS lines, the 'ath79_spi_setup_cs' function does the
opposite of that due to the wrong GPIO flags.
Fix the code to use the correct GPIO flags.
Reported-by: Ronald Wahl <ronald.wahl@raritan.com>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org
The clean-up in commit 36281caa83 ended up removing a NULL pointer check
that is needed in order to prevent an Oops in
nfs_async_inode_return_delegation().
Reported-by: "Yan, Zheng" <zheng.z.yan@intel.com>
Link: http://lkml.kernel.org/r/5313E9F6.2020405@intel.com
Fixes: 36281caa83 (NFSv4: Further clean-ups of delegation stateid validation)
Cc: stable@vger.kernel.org # 3.4+
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
