This reverts
commit 047fe6e6db
Author: David Weinehall <david.weinehall@linux.intel.com>
Date: Tue Aug 4 16:55:52 2015 +0300
drm/i915: Allow parsing of variable size child device entries from VBT
That commit is not valid for v4.2, however it will be valid for v4.3. It
was simply queued too early.
The referenced regressing commit is just fine until the size of struct
common_child_dev_config changes, and that won't happen until
v4.3. Indeed, the expected size checks here rely on the increased size
of the struct, breaking new platforms.
Fixes: 047fe6e6db ("drm/i915: Allow parsing of variable size child device entries from VBT")
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
REPORT LUNS should not fail just because the allocation length is less
than 16. The relevant section of SPC-4 is:
4.2.5.6 Allocation length
The ALLOCATION LENGTH field specifies the maximum number of bytes or
blocks that an application client has allocated in the Data-In
Buffer. The ALLOCATION LENGTH field specifies bytes unless a
different requirement is stated in the command definition.
An allocation length of zero specifies that no data shall be
transferred. This condition shall not be considered an error.
So we should just truncate our response rather than return an error.
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Spencer Baugh <sbaugh@catern.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
The object tt_local is allocated with kmalloc and not initialized when the
function batadv_tt_local_add checks for the vlan. But this function can
only cleanup the object when the (not yet initialized) reference counter of
the object is 1. This is unlikely and thus the object would leak when the
vlan could not be found.
Instead the uninitialized object tt_local has to be freed manually and the
pointer has to set to NULL to avoid calling the function which would try to
decrement the reference counter of the not existing object.
CID: 1316518
Fixes: 354136bcc3 ("batman-adv: fix kernel crash due to missing NULL checks")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
We recently found issue with dma_request_slave_channel() API causing
privatecnt value to go bad. This is fixed by balancing the privatecnt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJV02dfAAoJEHwUBw8lI4NHcDgQAMM4q0cQkLiPiL1RFFwg8sfm
LkTP+beefke/lEpqpOvvTNkyfc3JwYbmDiVFl0dNJ4iI3VjWR9Xfg4ZPsG54RQcc
hrvUamiPuotBNFX9ohRoyq7VLaqy/fd0PksPaXNDh1Gy9zXpt3bFC8w/1mRtVyE8
hFKWO+ZLr1KayGDpoQ4JjtVCNoR6oO/j9eCJ12+27n/IEnxPtuoUtBr5lqIC2cRZ
y0YSPokrTB/uVGzdDTeS5S0uM0YtSHmiVcd5msI8k5FioN/1HpKf6u2ls/1AvC8R
IPwHwbj92M33LtdI18SrUaTt0boKW6vcgd5jFnPD9EA68crEbfONjGigSx6/CJNY
tlCMTJ3oIHw/jbT39Yq00F/Tds3wk3BlFM87xRCyzlCE3vN6d42xyjuHJmqOp5xt
PKpTtiIVBjVEMsstyV5pnior3SN5uWuFnldYzQR7op0RkAdWuhzOVCJiEeFLCDWy
J2ra6JdM2uRYBMzIOsiL7cy0btg401mYAzNOezqaDT1D5Aifi4J2r8LKQO+FRqnU
gmtynMUuBB7xKJMwl4iR9fWAvEN0pXQ/OlZOrkXM9LJ0gdTmOp4kBRm2h7AjrcBi
/VKmMmoQ82Bv4IgzbrlkLKWN/rba8kotzRB0gszDSaU9fH01+LmKs2ygOVQQRI24
K9xLshDvIJheh4mDRlia
=nKrX
-----END PGP SIGNATURE-----
Merge tag 'dmaengine-fix-4.2-rc8' of git://git.infradead.org/users/vkoul/slave-dma
Pull dmaengine fix from Vinod Koul:
"We recently found issue with dma_request_slave_channel() API causing
privatecnt value to go bad. This is fixed by balancing the privatecnt"
* tag 'dmaengine-fix-4.2-rc8' of git://git.infradead.org/users/vkoul/slave-dma:
dmaengine: fix balance of privatecnt inc/dec operations
Since the topology API is still in sufficient flux for changes to be
identified disable the use of the userspace ABI by adding #error
statements to the code, ensuring that nobody relies on the headers as
currently defined. It is expected that this change will be reverted for
v4.3.
Signed-off-by: Mark Brown <broonie@kernel.org>
Alex Deucher, Mark Rustad and Alexander Holler reported a regression
with the latest v4.2-rc4 kernel, which breaks some SATA controllers.
With multi-MSI capable SATA controllers, only the first port works,
all other ports time out when executing SATA commands.
This happens because the first argument to assign_irq_vector_policy()
is always the base linux irq number of the multi MSI interrupt block,
so all subsequent vector assignments operate on the base linux irq
number, so all MSI irqs are handled as the first irq number. Therefor
the other MSI irqs of a device are never set up correctly and never
fire.
Add the loop iterator to the base irq number so all vectors are
assigned correctly.
Fixes: b5dc8e6c21 "x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors"
Reported-and-tested-by: Alex Deucher <alexdeucher@gmail.com>
Reported-and-tested-by: Mark Rustad <mrustad@gmail.com>
Reported-and-tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/1439911228-9880-1-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The routines in scsi_rpm.c assume that if a runtime-PM callback is
invoked for a SCSI device, it can only mean that the device's driver
has asked the block layer to handle the runtime power management (by
calling blk_pm_runtime_init(), which among other things sets q->dev).
However, this assumption turns out to be wrong for things like the ses
driver. Normally ses devices are not allowed to do runtime PM, but
userspace can override this setting. If this happens, the kernel gets
a NULL pointer dereference when blk_post_runtime_resume() tries to use
the uninitialized q->dev pointer.
This patch fixes the problem by calling the block layer's runtime-PM
routines only if the device's driver really does have a runtime-PM
callback routine. Since ses doesn't define any such callbacks, the
crash won't occur.
This fixes Bugzilla #101371.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Stanisław Pitucha <viraptor@gmail.com>
Reported-by: Ilan Cohen <ilanco@gmail.com>
Tested-by: Ilan Cohen <ilanco@gmail.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Odin.com>
We added changes in fnic driver patch 1.6.0.16 to acquire
io_req_lock in fnic_queuecommand() before issuing I/O so that io completion
is serialized. But when releasing the lock we check for the I/O flag and
this could be modified if IO abort occurs before I/O completion. In this case
we wont release the lock and causes deadlock in some scenerios. Using the
local variable to check the IO lock status will resolve the problem.
Fixes: 41df7b02db
Signed-off-by: Hiral Shah <hishah@cisco.com>
Signed-off-by: Sesidhar Baddela <sebaddel@cisco.com>
Signed-off-by: Anil Chintalapati <achintal@cisco.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Pull drm fixes from Dave Airlie:
"These came in late last week, I wanted to look over the mst one before
forwarding, but it seems good.
Just three i915 and one MST fix"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/i915: Commit planes on each crtc separately.
drm/i915: calculate primary visibility changes instead of calling from set_config
drm/i915: Only dither on 6bpc panels
drm/dp/mst: Remove port after removing connector.
lock_timer_base() cannot prevent the following :
CPU1 ( in __mod_timer()
timer->flags |= TIMER_MIGRATING;
spin_unlock(&base->lock);
base = new_base;
spin_lock(&base->lock);
// The next line clears TIMER_MIGRATING
timer->flags &= ~TIMER_BASEMASK;
CPU2 (in lock_timer_base())
see timer base is cpu0 base
spin_lock_irqsave(&base->lock, *flags);
if (timer->flags == tf)
return base; // oops, wrong base
timer->flags |= base->cpu // too late
We must write timer->flags in one go, otherwise we can fool other cpus.
Fixes: bc7a34b8b9 ("timer: Reduce timer migration overhead if disabled")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jon Christopherson <jon@jons.org>
Cc: David Miller <davem@davemloft.net>
Cc: xen-devel@lists.xen.org
Cc: david.vrabel@citrix.com
Cc: Sander Eikelenboom <linux@eikelenboom.it>
Link: http://lkml.kernel.org/r/1439831928.32680.11.camel@edumazet-glaptop2.roam.corp.google.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
U-Boot is often used to boot the kernel on ARM boards, but uImage
is not built by "make all", so we are often inclined to do
"make all uImage" to generate DTBs, modules and uImage in a single
command, but we should notice a pitfall behind it. In fact,
"make all uImage" could generate an invalid uImage if it is run with
the parallel option (-j).
You can reproduce this problem with the following procedure:
[1] First, build "all" and "uImage" separately.
You will get a valid uImage
$ git clean -f -x -d
$ export CROSS_COMPILE=<your-tools-prefix>
$ make -s -j8 ARCH=arm multi_v7_defconfig
$ make -s -j8 ARCH=arm all
$ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CHK include/generated/timeconst.h
CHK include/generated/bounds.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready
UIMAGE arch/arm/boot/uImage
Image Name: Linux-4.2.0-rc5-00156-gdd2384a-d
Created: Sat Aug 8 23:21:35 2015
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6138648 Bytes = 5994.77 kB = 5.85 MB
Load Address: 80208000
Entry Point: 80208000
Image arch/arm/boot/uImage is ready
$ ls -l arch/arm/boot/*Image
-rwxrwxr-x 1 masahiro masahiro 13766656 Aug 8 23:20 arch/arm/boot/Image
-rw-rw-r-- 1 masahiro masahiro 6138712 Aug 8 23:21 arch/arm/boot/uImage
-rwxrwxr-x 1 masahiro masahiro 6138648 Aug 8 23:20 arch/arm/boot/zImage
[2] Update some source file(s)
$ touch init/main.c
[3] Then, re-build "all" and "uImage" simultaneously.
You will get an invalid uImage at random.
$ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 all uImage
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CHK include/generated/timeconst.h
CHK include/generated/bounds.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CC init/main.o
CHK include/generated/compile.h
LD init/built-in.o
LINK vmlinux
LD vmlinux.o
MODPOST vmlinux.o
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
KSYM .tmp_kallsyms1.o
KSYM .tmp_kallsyms2.o
LD vmlinux
SORTEX vmlinux
SYSMAP System.map
OBJCOPY arch/arm/boot/Image
Building modules, stage 2.
Kernel: arch/arm/boot/Image is ready
GZIP arch/arm/boot/compressed/piggy.gzip
AS arch/arm/boot/compressed/piggy.gzip.o
Kernel: arch/arm/boot/Image is ready
LD arch/arm/boot/compressed/vmlinux
GZIP arch/arm/boot/compressed/piggy.gzip
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
UIMAGE arch/arm/boot/uImage
Image Name: Linux-4.2.0-rc5-00156-gdd2384a-d
Created: Sat Aug 8 23:23:14 2015
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 26472 Bytes = 25.85 kB = 0.03 MB
Load Address: 80208000
Entry Point: 80208000
Image arch/arm/boot/uImage is ready
MODPOST 192 modules
AS arch/arm/boot/compressed/piggy.gzip.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
$ ls -l arch/arm/boot/*Image
-rwxrwxr-x 1 masahiro masahiro 13766656 Aug 8 23:23 arch/arm/boot/Image
-rw-rw-r-- 1 masahiro masahiro 26536 Aug 8 23:23 arch/arm/boot/uImage
-rwxrwxr-x 1 masahiro masahiro 6138648 Aug 8 23:23 arch/arm/boot/zImage
Please notice the uImage is extremely small when this issue is
encountered. Besides, "Kernel: arch/arm/boot/zImage is ready" is
displayed twice, before and after the uImage log.
The root cause of this is the race condition between zImage and
uImage. Actually, uImage depends on zImage, but the dependency
between the two is only described in arch/arm/boot/Makefile.
Because arch/arm/boot/Makefile is not included from the top-level
Makefile, it cannot know the dependency between zImage and uImage.
Consequently, when we run make with the parallel option, Kbuild
updates vmlinux first, and then two different threads descends into
the arch/arm/boot/Makefile almost at the same time, one for updating
zImage and the other for uImage. While one thread is re-generating
zImage, the other also tries to update zImage before creating uImage
on top of that. zImage is overwritten by the slower thread and then
uImage is created based on the half-written zImage.
This is the reason why "Kernel: arch/arm/boot/zImage is ready" is
displayed twice, and a broken uImage is created.
The same problem could happen on bootpImage.
This commit adds dependencies among Image, zImage, uImage, and
bootpImage to arch/arm/Makefile, which is included from the
top-level Makefile.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The mmap semaphore should not be taken when page faults are disabled.
Since pagefault_disable() no longer disables preemption, we now need
to use faulthandler_disabled() in place of in_atomic().
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
I2CM_ADDRESS became a MESS, fix it, also change guarding define
to __DW_HDMI_H__ , since the driver is not IMX specific.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The dw_hdmi enable/disable handling is particularly weak in several
regards:
* The hotplug interrupt could call hdmi_poweron() or hdmi_poweroff()
while DRM is setting a mode, which could race with a mode being set.
* Hotplug will always re-enable the phy whenever it detects an active
hotplug signal, even if DRM has disabled the output.
Resolve all of these by introducing a mutex to prevent races, and a
state-tracking bool so we know whether DRM wishes the output to be
enabled. We choose to use our own mutex rather than ->struct_mutex
so that we can still process interrupts in a timely fashion.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
dw_hdmi_phy_enable_power() is not about enabling and disabling power.
It is about allowing or preventing power-down mode being entered - the
register is documented as "Power-down enable (active low 0b)."
This can be seen as the bit has no effect when the HDMI phy is
operational on iMX6 hardware.
Rename the function to dw_hdmi_phy_enable_powerdown() to reflect the
documentation, make it take a bool for the 'enable' argument, and invert
the value to be written.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On a mode set, DRM makes the following sequence of calls:
* for_each_encoder
* bridge mode_fixup
* encoder mode_fixup
* crtc mode_fixup
* for_each_encoder
* bridge disable
* encoder prepare
* bridge post_disable
* disable unused encoders
* crtc prepare
* crtc mode_set
* for_each_encoder
* encoder mode_set
* bridge mode_set
* crtc commit
* for_each_encoder
* bridge pre_enable
* encoder commit
* bridge enable
dw_hdmi enables the HDMI output in both the bridge mode_set() and also
the bridge enable() step. This is duplicated work - we can avoid the
setup in mode_set() and just do it in the enable() stage. This
simplifies the code a little.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Only enable audio support if the sink supports audio in some form, as
defined via its EDID. We discover this capability using the generic
drm_detect_monitor_audio() function.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The FSL kernel detects the HDMI vendor id, and uses this to set
hdmi->edid_cfg.hdmi_cap, which is then used to set mdvi appropriately,
rather than detecting whether we are outputting a CEA mode. Update
the dw_hdmi code to use this logic, but lets eliminate the mdvi
variable, prefering the more verbose "hdmi->sink_is_hdmi" instead.
Use the generic drm_detect_hdmi_monitor() to detect a HDMI sink.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
As mentioned in the previous commit, the dw-hdmi driver does not support
pixel doubled modes at present; it does not configure the PLL correctly
for these modes. Therefore, filter out the double-clocked modes as we
presently are unable to support them.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
dw_hdmi sets a pixel repetition factor of 1 for VICs 10-15, 25-30 and
35-38. However, DRM uses their native resolutions in its timing
information. For example, VIC 14 can be 1440x480 with no repetition,
or 720x480 with one pixel repetition. As DRM uses 1440 pixels per line
for this video mode, we need no pixel repetition.
In any case, pixel repetition appears broken in dw_hdmi.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
iMX6 devices suffer from an errata (ERR005174) where the audio FIFO can
be emptied while it is partially full, resulting in misalignment of the
audio samples.
To prevent this, the errata workaround recommends writing N as zero
until the audio FIFO has been loaded by DMA. Writing N=0 prevents the
HDMI bridge from reading from the audio FIFO, effectively disabling
audio.
This means we need to provide the audio driver with a pair of functions
to enable/disable audio. These are dw_hdmi_audio_enable() and
dw_hdmi_audio_disable().
A spinlock is introduced to ensure that setting the CTS/N values can't
race, ensuring that the audio driver calling the enable/disable
functions (which are called in an atomic context) can't race with a
modeset.
Tested-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Introduce dw_hdmi_set_sample_rate(), which allows us to configure the
audio sample rate, setting the CTS/N values appropriately.
Tested-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove the struct hdmi_vmode mhsyncpolarity/mvsyncpolarity/minterlaced
members, which are only used within a single function. We can directly
reference the appropriate mode->flags instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When a YCBCR format is selected, we can merely copy the colorimetry
information directly as we use the same definitions for both the
unpacked AVI info frame and the hdmi_data_info structure.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Clean up hdmi_set_clk_regenerator() by allowing it to take the audio
sample rate and ratio directly, rather than hiding it inside the
function. Raise the unsupported pixel clock/sample rate message from
debug to error level as this results in audio not working correctly.
Tested-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The phy configuration is dependent on the SoC, and we look up values for
some of the registers in SoC specific data. However, we had partially
programmed the phy before we had successfully looked up the clock rate.
Also, we were only checking that we had a valid configuration for the
currctrl register.
Move all these lookups to the start of this function instead, so we can
check that all lookups were successful before beginning to program the
phy.
Tested-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The phy comments in dw_hdmi.c applied to the iMX6 version. Move these
comments to the iMX6 dw_hdmi-imx data along side the data.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add a function to find the start of the SADs in the ELD. This
complements the helper to retrieve the SAD count.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Matthew Fortune <Matthew.Fortune@imgtec.com> reports:
The genex.S file appears to mix the case of a macro between its definition and
use. A cut down example of this is below. The macro __build_clear_none has
lower case 'build' but ends up being instantiated with upper case BUILD. Can
this be fixed on master. It has been picked up by the LLVM integrated assembler
which is currently case sensitive. We are likely to fix the assembler as well
but the code is currently inconsistent in the kernel.
.macro __build_clear_none
.endm
.macro __BUILD_HANDLER exception handler clear verbose ext
.align 5
.globl handle_\exception; .align 2; .type handle_\exception, @function; .ent
handle_\exception, 0; handle_\exception: .frame $29, 184, $29
.set noat
.globl handle_\exception\ext; .type handle_\exception\ext, @function;
handle_\exception\ext:
__BUILD_clear_\clear
.endm
.macro BUILD_HANDLER exception handler clear verbose
__BUILD_HANDLER \exception \handler \clear \verbose _int
.endm
BUILD_HANDLER ftlb ftlb none silent
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Reported-by: Matthew Fortune <Matthew.Fortune@imgtec.com>
Describe capabilities of the HLCDC IP found on sama5d4 SoCs and add a
new entry to the atmel_hlcdc_of_match table.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Describe capabilities of the HLCDC IP found on at91sam9n12 SoC and add a
new entry to the atmel_hlcdc_of_match table.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Describe capabilities of the HLCDC IP found on at91sam9x5 SoCs and add a
new entry to the atmel_hlcdc_of_match table.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
The atmel-hlcdc driver already supports atomic operations, add the
missing DRM_ATOMIC flag to expose the atomic features to userspace.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
If PM is enabled but PM_SLEEP is disabled, the suspend/resume functions
are still unused and produce a compiler warning.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: <stable@vger.kernel.org> # 4.1+
This reverts commit:
2c7577a758 ("sched/x86_64: Don't save flags on context switch")
It was a nice speedup. It's also not quite correct: SYSENTER
enables interrupts too early.
We can re-add this optimization once the SYSENTER code is beaten
into shape, which should happen in 4.3 or 4.4.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org # v3.19
Link: http://lkml.kernel.org/r/85f56651f59f76624e80785a8fd3bdfdd089a818.1439838962.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Allow the topology code to be compiled out so that users who don't need
topology don't need to havve the code compiled in, saving them some
memory.
Some more configuration could be added to remove some of the hooks into
the core data structures but that is probably best done with some
refactoring to use functions to do the updates of the data structures
rather than ifdefing in the code as we'd need to do at the minute.
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Pull libata fixes from Tejun Heo:
"Three minor device-specific fixes and revert of NCQ autosense added
during this -rc1.
It turned out that NCQ autosense as currently implemented interferes
with the usual error handling behavior. It will be revisited in the
near future"
* 'for-4.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
ata: ahci_brcmstb: Fix misuse of IS_ENABLED
sata_sx4: Check return code from pdc20621_i2c_read()
Revert "libata: Implement NCQ autosense"
Revert "libata: Implement support for sense data reporting"
Revert "libata-eh: Set 'information' field for autosense"
ata: ahci_brcmstb: Fix warnings with CONFIG_PM_SLEEP=n
Pull cgroup fix from Tejun Heo:
"A fix for a subtle bug introduced back during 3.17 cycle which
interferes with setting configurations under specific conditions"
* 'for-4.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
cpuset: use trialcs->mems_allowed as a temp variable
VxLAN offloading is not functional if the NIC is running in multichannel
mode (UMC, FLEX-10, VNIC...). Enabling this additionally kills whole
connectivity through the NIC and the device needs to be down and up to
restore it. The firmware should take care about it and does not allow
the conversion of interface to tunnel type (be_cmd_manage_iface) or should
support VxLAN offloading if multichannel config is enabled.
I have tested this on the latest available firmware (10.6.144.21).
Result:
[root@sm-04 ~]# ip link set enp5s0f0 up[root@sm-04 ~]# ip addr add 172.30.10.50/24 dev enp5s0f0
[root@sm-04 ~]# ping -c 3 172.30.10.254PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data.
64 bytes from 172.30.10.254: icmp_seq=1 ttl=64 time=0.317 ms
64 bytes from 172.30.10.254: icmp_seq=2 ttl=64 time=0.187 ms
64 bytes from 172.30.10.254: icmp_seq=3 ttl=64 time=0.188 ms
--- 172.30.10.254 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.187/0.230/0.317/0.063 ms
[root@sm-04 ~]# ip link add link enp5s0f0 vxlan10 type vxlan id 10 remote 172.30.10.60 dstport 4789
[root@sm-04 ~]# ip link set vxlan10 up
[ 7900.442811] be2net 0000:05:00.0: Enabled VxLAN offloads for UDP port 4789
[ 7900.455722] be2net 0000:05:00.1: Enabled VxLAN offloads for UDP port 4789
[ 7900.468635] be2net 0000:05:00.2: Enabled VxLAN offloads for UDP port 4789
[ 7900.481553] be2net 0000:05:00.3: Enabled VxLAN offloads for UDP port 4789
[root@sm-04 ~]# ping -c 3 172.30.10.254
PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data.
--- 172.30.10.254 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms
[root@sm-04 ~]# ip link set vxlan10 down
[ 7959.434093] be2net 0000:05:00.0: Disabled VxLAN offloads for UDP port 4789
[ 7959.444792] be2net 0000:05:00.1: Disabled VxLAN offloads for UDP port 4789
[ 7959.455592] be2net 0000:05:00.2: Disabled VxLAN offloads for UDP port 4789
[ 7959.466416] be2net 0000:05:00.3: Disabled VxLAN offloads for UDP port 4789
[root@sm-04 ~]# ip link del vxlan10
[root@sm-04 ~]# ping -c 3 172.30.10.254
PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data.
--- 172.30.10.254 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms
[root@sm-04 ~]# ip link set enp5s0f0 down
[root@sm-04 ~]# ip link set enp5s0f0 up
[ 8071.019003] be2net 0000:05:00.0 enp5s0f0: Link is Up
[root@sm-04 ~]# ping -c 3 172.30.10.254
PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data.
64 bytes from 172.30.10.254: icmp_seq=1 ttl=64 time=0.318 ms
64 bytes from 172.30.10.254: icmp_seq=2 ttl=64 time=0.196 ms
64 bytes from 172.30.10.254: icmp_seq=3 ttl=64 time=0.194 ms
--- 172.30.10.254 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.194/0.236/0.318/0.057 ms
Cc: Sathya Perla <sathya.perla@avagotech.com>
Cc: Ajit Khaparde <ajit.khaparde@avagotech.com>
Cc: Padmanabh Ratnakar <padmanabh.ratnakar@avagotech.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna@avagotech.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Ajit Khaparde <ajit.khaparde@avagotech.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Martin KaFai Lau says:
====================
ipv6: Fix a potential deadlock when creating pcpu rt
v1 -> v2:
A minor change in the commit message of patch 2.
This patch series fixes a potential deadlock when creating a pcpu rt.
It happens when dst_alloc() decided to run gc. Something like this:
read_lock(&table->tb6_lock);
ip6_rt_pcpu_alloc()
=> dst_alloc()
=> ip6_dst_gc()
=> write_lock(&table->tb6_lock); /* oops */
Patch 1 and 2 are some prep works.
Patch 3 is the fix.
Original report: https://bugzilla.kernel.org/show_bug.cgi?id=102291
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
It is a prep work for fixing a potential deadlock when creating
a pcpu rt.
The current rt6_get_pcpu_route() will also create a pcpu rt if one does not
exist. This patch moves the pcpu rt creation logic into another function,
rt6_make_pcpu_route().
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
