Add Freescale Vybrid family as a own entry, along with an entry for
the so far orphan Vybrid device tree files. Also add myself as
a designated reviewer.
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A normal wait adds to the front of the tail. By doing something
similar to fence_default_wait the fence code can run without racing.
This is a complete fix for "panic on suspend from KDE with radeon",
and a partial fix for "Radeon: System pauses on TAHITI". On tahiti
si_irq_set needs to be fixed too, to completely flush the writes
before radeon_fence_activity is called in radeon_fence_enable_signaling.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Reported-by: Jon Arne Jørgensen <jonjon.arnearne@gmail.com>
Reported-and-tested-by: Gustaw Smolarczyk <wielkiegie@gmail.com>
Cc: stable@vger.kernel.org (v3.18+)
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
USB vbus 5V is from PMIC SWBST, so set swbst_reg as vbus's
parent reg, it fixed a bug that the voltage of vbus is incorrect
due to swbst_reg is disabled after boots up.
Cc: stable@vger.kernel.org
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
USB vbus 5V is from PMIC SWBST, so set swbst_reg as vbus's
parent reg, it fixed a bug that the voltage of vbus is incorrect
due to swbst_reg is disabled after boots up.
Cc: stable@vger.kernel.org
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
* pxa3xx_nand
- fix timeout issues when draining the FIFO (BCH only)
- don't crash when no chip-selects are used
* hisi504_nand
- depend on HAS_DMA, to fix compile errors
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJU/4s9AAoJEFySrpd9RFgtTp8P/AoOj+FoRZAjIcr1oRRvIj68
gUJTihk/2caf4PzLek1mk2BMHbs3axvnyNEGyXeTkPBnM03ZSMkq0MCdCF+qpGpV
qWnkUG3Q1SlMTkhOr1Uq28DZpkx5PVi5j859wKxw9wfkprUXb5JksX2qno+Hmfet
+CYp+65tU/6xNeaLGtDawfxvsVXEn40hKfP7JGYfyrrbQ3jEcCuZRm19fDb+JtTg
W8oBR08CwSoOKmpcNyltHsjlmDiF35/u0pdfIZxym1BFWyLXAsmV723MtI9J2ILG
hEHZZwG3rxyrV/JBFl6sPlcyU6zQGmXl3rCrEoK/rxqmY00gY2x9fsqGCJOUls+u
A6aCoIjlJ/EOuRBm+wpyEopuljZ6ybVAkdMRmiY2cIt1oOcvMtkRQzw+I+9i/fLa
qQuhqPlEFwB63TCsi/xVwNL8VXpeBfhsSTAeE/y2ZJFuKmOym040eoENKWoEThY/
8Nhma3sLazeSCW4vX1r5glPP0sseARo0/z9HhzjRe249VBjR7Zz60/GoF4cCXW63
RJNXHfvxPbWvOPizT6x6HxlGcZX6dq18wgvBV46uxX2a0X3r1G3qtluyrNZHO3ab
T2lG8Yx44uN+Bwbaxh74UB/RgvDBxeNoVf5onc+u1MhN1QU/09NfroLIY5eLEDcf
d0+yZdOFKvYjY7pU1SFa
=GF4t
-----END PGP SIGNATURE-----
Merge tag 'for-linus-20150310' of git://git.infradead.org/linux-mtd
Pull MTD fixes from Brian Norris:
* pxa3xx_nand
- fix timeout issues when draining the FIFO (BCH only)
- don't crash when no chip-selects are used
* hisi504_nand
- depend on HAS_DMA, to fix compile errors
* tag 'for-linus-20150310' of git://git.infradead.org/linux-mtd:
mtd: nand: MTD_NAND_HISI504 should depend on HAS_DMA
mtd: pxa3xx_nand: fix driver when num_cs is 0
mtd: nand: pxa3xx: Fix PIO FIFO draining
The patches contain:
* Fix multiple ARM IOMMU drivers to behave well when the
hardware is not present
* Mark MSM driver as broken
* Fix build errors with the new ARM generic io-page-table code
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJU/zbaAAoJECvwRC2XARrjZFsP/2rZAiDJ1NGBOoJO+v+QlEY/
//wxpyKWnJ977vkgIAVvBZqWLFbwO8UF3jnRlfF4nrpbkbRynB62kczov9G/3Mzo
kur1gT472xYSTd87yGfBKl9hfIn5GQpe8BFX3UU9SkkSR11z7iDBb6X7LevmeyqB
B24WgzX0haKCSYMj5/jd1iskzI1KomhoLLUrh5+vmDHj12P9B2TmCuK/6hZOBtQI
GSCvrje3FWHdymCfGym2QZmwQIdm6ZlvzSBuTLp8F3PUKbf7hVvpszCbMRJ/ZYCl
gDvn0mDXyi14heEeXzHVF6574Sd1UBfxRWpgmDQpDRUAREzt3NW+FUbwMQg1XnzD
nN8ft1QCjhzK2elb0rsp6ZN4tkLEGZMU/EgUfnrLvt9/yhhOzwN7u2tDIXpM5dwW
KsgX/cKQssH8tJBfRy8YyXmb6ez9nV3yo0byHUCrC5YlCYrSGEpSe9mMstO5/Zo7
UFL0OPdbscdU1H2kYTA8YA1RywmUM/icn8mTrh/B2qkhxwusEJeqj4UOmtM3oiwF
RuUp3hfeYYuDaDIiAsJ0yaaSMdmQ2LummJClYJOVVOSAKacLWwG4HkyBLSrMIiol
H30cUEtGGnSbrptnYAI5M3gVFuNj1kTVjSw2ccc3EaEiAC7/iOPk4ho52ItEAkpT
ZGCBV1jtJ51RNeOh8r66
=dL5c
-----END PGP SIGNATURE-----
Merge tag 'iommu-fixes-v4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull iommu fixes from Joerg Roedel:
"The patches contain:
- fix multiple ARM IOMMU drivers to behave well when the hardware is
not present
- mark MSM driver as broken
- fix build errors with the new ARM generic io-page-table code"
* tag 'iommu-fixes-v4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/io-pgtable-arm: Add built time dependency
iommu/msm: Mark driver BROKEN
iommu/rockchip: Play nice in multi-platform builds
iommu/omap: Play nice in multi-platform builds
iommu/exynos: Play nice in multi-platform builds
iommu/io-pgtable-arm: Fix self-test WARNs on i386
Add testcase variants with '/' in the options string to test for
scan beyond end path name terminated by ':'.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Ensure proper handling of paths with appended options (after ':'),
where those options may contain a '/'.
Fixes: 7914a7c565 ("of: support passing console options with stdout-path")
Reported-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Cc: <stable@vger.kernel.org> # 3.19
Signed-off-by: Rob Herring <robh@kernel.org>
This patch fix the wrong expected value of of_property_match_string
in of_selftest_property_string.
Signed-off-by: Wang Long <long.wanglong@huawei.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Remove the duplicate of_changeset_init. In of_selftest_changeset
testcase, the "struct of_changeset chgset" is initialized twice,
but only once is enough. so, drop the first initializtion code.
Signed-off-by: Wang Long <long.wanglong@huawei.com>
Signed-off-by: Rob Herring <robh@kernel.org>
The exact steps provided for submitting binding patches can be read
as requiring the bindings to be sent only to the devicetree@vger.kernel.org
list. Since the DT maintainers would like to be Cced on any binding
submissions, make this requirement explicit in step 2.
Signed-off-by: Matt Porter <mporter@konsulko.com>
Signed-off-by: Rob Herring <robh@kernel.org>
The unittest fails to link if I2C or I2C_MUX is a loadable module:
drivers/built-in.o: In function `selftest_i2c_mux_remove':
unittest.c:(.text+0xb0ce4): undefined reference to `i2c_del_mux_adapter'
This changes the newly added IS_ENABLED() checks to use IS_BUILTIN()
instead, which evaluates to false if the other driver is a module.
Reported-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: d5e75500ca ("of: unitest: Add I2C overlay unit tests.")
Signed-off-by: Rob Herring <robh@kernel.org>
Commit 3e7f7626fd ("of/overlay: Do not generate duplicate nodes") removed
the only use of the 'grandchild' variable, which leads to the following build
warning:
drivers/of/overlay.c: In function 'of_overlay_apply_single_device_node':
drivers/of/overlay.c:89:31: warning: unused variable 'grandchild' [-Wunused-variable]
struct device_node *tchild, *grandchild;
^
Remove this unused variable.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Rob Herring <robh@kernel.org>
The file of-serial.txt was only for 8250 compatible UART implementations,
so renamed it to 8250.txt to avoid confusing other persons.
This is suggested by Arnd, see:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/291455.html
Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Support for devicetree serial consoles via 'stdout-path' causes
bootconsoles to be disabled when the vt dummy console loads, since
there is no preferred console (the preferred console is not added
until the device is probed).
Ensure there is at least a preferred console, even if never matched.
Requires: "console: Fix console name size mismatch"
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Rob Herring <robh@kernel.org>
With previous commit, this module managed to leave the counting to each
drivers, but the isochronous resources functionality still increment/decrement
the count.
This commit purge such codes to leave the responsibility to each drivers.
Fix: c6f224dc20 ('ALSA: firewire-lib: remove reference counting')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJU/NacAAoJEHm+PkMAQRiGdUcIAJU5dHclwd9HRc7LX5iOwYN6
mN0aCsYjMD8Pjx2VcPCgJvkIoESQO5pkwYpFFWCwILup1bVEidqXfr8EPOdThzdh
kcaT0FwUvd19K+0jcKVNCX1RjKBtlUfUKONk6sS2x4RrYZpv0Ur8Gh+yXV8iMWtf
fAusNEYlxQJvEz5+NSKw86EZTr4VVcykKLNvj+/t/JrXEuue7IG8EyoAO/nLmNd2
V/TUKKttqpE6aUVBiBDmcMQl2SUVAfp5e+KJAHmizdDpSE80nU59UC1uyV8VCYdM
qwHXgttLhhKr8jBPOkvUxl4aSXW7S0QWO8TrMpNdEOeB3ZB8AKsiIuhe1JrK0ro=
=Xkue
-----END PGP SIGNATURE-----
Merge tag 'v4.0-rc3' into HEAD
Linux 4.0-rc3
Merging in v4.0-rc3 because commit 30a22c215a (console: Fix
console name size mismatch) is a dependency.
Long ago I found that I was getting sporadic errors when booting SNB,
with the symptom being that the first batch died with IPEHR != *ACTHD,
typically caused by the TLB being invalid. These magically disappeared
if I held the forcewake during the entire ring initialisation sequence.
(It can probably be shortened to a short critical section, but the whole
initialisation is full of register writes and so we would be taking and
releasing forcewake almost continually, and so holding it over the
entire sequence will probably be a net win!)
Note some of the kernels I encounted the issue already had the deferred
forcewake release, so it is still relevant.
I know that there have been a few other reports with similar failure
conditions on SNB, I think such as
References: https://bugs.freedesktop.org/show_bug.cgi?id=80913
v2: Wrap i915_gem_init_hw() with its own security blanket as we take
that path following resume and reset.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
commit 05a2fb157e ("drm/i915: Consolidate forcewake code")
failed to take into account that we have used to reset both
the gen6 style and the multithreaded style forcewake registers.
This is due to fact that ivb can use either, depending on how the
bios has set up the machine.
Mimic the old semantics before we have determined the correct variety
and reset both before the ecobus probe.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This fixes a regression from
commit 5ed0bdf21a
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Wed Jul 16 21:05:06 2014 +0000
drm: i915: Use nsec based interfaces
that made a negative timeout return immediately rather than the
previously defined behaviour of waiting indefinitely.
Testcase: igt/gem_wait
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89494
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: fixed a checkpatch complaint about whitespace.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The kernel in_irq() function tests for hard-IRQ context only, so if a
system is run with the kernel 'threadirqs' option selected, the test in
intel_check_page_flip() generates lots of warnings, because then it gets
called in soft-IRQ context.
We can instead use in_interrupt() which allows for either type of
interrupt, while still detecting and complaining about misuse of the
page flip code if it is ever called from non-interrupt context.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89321
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
With drm-next, we can get a backtrace from sleeping
with mutex detection.
this is due to the callback checking the txmsg state taking
the mutex, which can cause a sleep inside a sleep,
Daniel went over it and was happy we could drop this mutex
in this case.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pull kvm/s390 bugfixes from Marcelo Tosatti.
* git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: s390: non-LPAR case obsolete during facilities mask init
KVM: s390: include guest facilities in kvm facility test
KVM: s390: fix in memory copy of facility lists
KVM: s390/cpacf: Fix kernel bug under z/VM
KVM: s390/cpacf: Enable key wrapping by default
Pull s390 fixes from Martin Schwidefsky:
"One performance optimization for page_clear and a couple of bug fixes"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/mm: fix incorrect ASCE after crst_table_downgrade
s390/ftrace: fix crashes when switching tracers / add notrace to cpu_relax()
s390/pci: unify pci_iomap symbol exports
s390/pci: fix [un]map_resources sequence
s390: let the compiler do page clearing
s390/pci: fix possible information leak in mmio syscall
s390/dcss: array index 'i' is used before limits check.
s390/scm_block: fix off by one during cluster reservation
s390/jump label: improve and fix sanity check
s390/jump label: add missing jump_label_apply_nops() call
The internal framebuffers we create to remap legacy cursor ioctls to
plane operations for the universal plane support shouldn't be linke to
the file like normal userspace framebuffers. This bug goes back to the
original universal cursor plane support introduced in
commit 161d0dc1dc
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Jun 10 08:28:10 2014 -0700
drm: Support legacy cursor ioctls via universal planes when possible (v4)
The isn't too disastrous since fbs are small, we only create one when the
cursor bo gets changed and ultimately they'll be reaped when the window
server restarts.
Conceptually we'd want to just pass NULL for file_priv when creating it,
but the driver needs the file to lookup the underlying buffer object for
cursor id. Instead let's move the file_priv linking out of
add_framebuffer_internal() into the addfb ioctl implementation, which is
the only place it is needed. And also rename the function for a more
accurate since it only creates the fb, but doesn't add it anywhere.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (fix & commit msg)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (provider of lipstick)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
contains fixes to ftrace when /proc/sys/kernel/ftrace_enabled and
function tracing are started. Doing the following causes some issues:
# echo 0 > /proc/sys/kernel/ftrace_enabled
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /proc/sys/kernel/ftrace_enabled
# echo nop > /sys/kernel/debug/tracing/current_tracer
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
As well as with function tracing too. Pratyush Anand first reported
this issue to me and supplied a patch. When I tested this on my x86
test box, it caused thousands of backtraces and warnings to appear in
dmesg, which also caused a denial of service (a warning for every
function that was listed). I applied Pratyush's patch but it did not
fix the issue for me. I looked into it and found a slight problem
with trampoline accounting. I fixed it and sent Pratyush a patch, but
he said that it did not fix the issue for him.
I later learned tha Pratyush was using an ARM64 server, and when I tested
on my ARM board, I was able to reproduce the same issue as Pratyush.
After applying his patch, it fixed the problem. The above test uncovered
two different bugs, one in x86 and one in ARM and ARM64. As this looked
like it would affect PowerPC, I tested it on my PPC64 box. It too broke,
but neither the patch that fixed ARM or x86 fixed this box (the changes
were all in generic code!). The above test, uncovered two more bugs that
affected PowerPC. Again, the changes were only done to generic code.
It's the way the arch code expected things to be done that was different
between the archs. Some where more sensitive than others.
The rest of this series fixes the PPC bugs as well.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJU/cQSAAoJEEjnJuOKh9lde9sH/1MAPq+6jr7YaEFru0GKajE9
rVHjw8rde/I4tN2UxIVk+Qm6pXRZYpv3OKxHT48EHzkvgm++voioykpJP4IEVrP5
mEDuIcYe28csE2nV5u5Q9kwnZoC86TQW5nVV6zB1Gx/3IEzA8Z046jAov40Jya0y
zqHc/U43JeeVIDIOkwjzbH6OaFEDP13FkF3TO502WJhJLqMo+kPOalIgv0eauKzy
lVCQBSC4WS3rVsgW4W3dSrEBaUxbJxgunjxOuV2DwHj5eghHq0M2MKeIUxBz0PuN
wnhTrpf5cAfshTvYHxKlE0uItdyYfVb7UChAD5zTbBL4kMUFhpb183zVKH8K8kU=
=8R8y
-----END PGP SIGNATURE-----
Merge tag 'trace-fixes-v4.0-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull seq-buf/ftrace fixes from Steven Rostedt:
"This includes fixes for seq_buf_bprintf() truncation issue. It also
contains fixes to ftrace when /proc/sys/kernel/ftrace_enabled and
function tracing are started. Doing the following causes some issues:
# echo 0 > /proc/sys/kernel/ftrace_enabled
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /proc/sys/kernel/ftrace_enabled
# echo nop > /sys/kernel/debug/tracing/current_tracer
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
As well as with function tracing too. Pratyush Anand first reported
this issue to me and supplied a patch. When I tested this on my x86
test box, it caused thousands of backtraces and warnings to appear in
dmesg, which also caused a denial of service (a warning for every
function that was listed). I applied Pratyush's patch but it did not
fix the issue for me. I looked into it and found a slight problem
with trampoline accounting. I fixed it and sent Pratyush a patch, but
he said that it did not fix the issue for him.
I later learned tha Pratyush was using an ARM64 server, and when I
tested on my ARM board, I was able to reproduce the same issue as
Pratyush. After applying his patch, it fixed the problem. The above
test uncovered two different bugs, one in x86 and one in ARM and
ARM64. As this looked like it would affect PowerPC, I tested it on my
PPC64 box. It too broke, but neither the patch that fixed ARM or x86
fixed this box (the changes were all in generic code!). The above
test, uncovered two more bugs that affected PowerPC. Again, the
changes were only done to generic code. It's the way the arch code
expected things to be done that was different between the archs. Some
where more sensitive than others.
The rest of this series fixes the PPC bugs as well"
* tag 'trace-fixes-v4.0-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
ftrace: Fix ftrace enable ordering of sysctl ftrace_enabled
ftrace: Fix en(dis)able graph caller when en(dis)abling record via sysctl
ftrace: Clear REGS_EN and TRAMP_EN flags on disabling record via sysctl
seq_buf: Fix seq_buf_bprintf() truncation
seq_buf: Fix seq_buf_vprintf() truncation
Pull networking fixes from David Miller:
1) nft_compat accidently truncates ethernet protocol to 8-bits, from
Arturo Borrero.
2) Memory leak in ip_vs_proc_conn(), from Julian Anastasov.
3) Don't allow the space required for nftables rules to exceed the
maximum value representable in the dlen field. From Patrick
McHardy.
4) bcm63xx_enet can accidently leave interrupts permanently disabled
due to errors in the NAPI polling exit logic. Fix from Nicolas
Schichan.
5) Fix OOPSes triggerable by the ping protocol module, due to missing
address family validations etc. From Lorenzo Colitti.
6) Don't use RCU locking in sleepable context in team driver, from Jiri
Pirko.
7) xen-netback miscalculates statistic offset pointers when reporting
the stats to userspace. From David Vrabel.
8) Fix a leak of up to 256 pages per VIF destroy in xen-netaback, also
from David Vrabel.
9) ip_check_defrag() cannot assume that skb_network_offset(),
particularly when it is used by the AF_PACKET fanout defrag code.
From Alexander Drozdov.
10) gianfar driver doesn't query OF node names properly when trying to
determine the number of hw queues available. Fix it to explicitly
check for OF nodes named queue-group. From Tobias Waldekranz.
11) MID field in macb driver should be 12 bits, not 16. From Punnaiah
Choudary Kalluri.
12) Fix unintentional regression in traceroute due to timestamp socket
option changes. Empty ICMP payloads should be allowed in
non-timestamp cases. From Willem de Bruijn.
13) When devices are unregistered, we have to get rid of AF_PACKET
multicast list entries that point to it via ifindex. Fix from
Francesco Ruggeri.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (38 commits)
tipc: fix bug in link failover handling
net: delete stale packet_mclist entries
net: macb: constify macb configuration data
MAINTAINERS: add Marc Kleine-Budde as co maintainer for CAN networking layer
MAINTAINERS: linux-can moved to github
can: kvaser_usb: Read all messages in a bulk-in URB buffer
can: kvaser_usb: Avoid double free on URB submission failures
can: peak_usb: fix missing ctrlmode_ init for every dev
can: add missing initialisations in CAN related skbuffs
ip: fix error queue empty skb handling
bgmac: Clean warning messages
tcp: align tcp_xmit_size_goal() on tcp_tso_autosize()
net: fec: fix unbalanced clk disable on driver unbind
net: macb: Correct the MID field length value
net: gianfar: correctly determine the number of queue groups
ipv4: ip_check_defrag should not assume that skb_network_offset is zero
net: bcmgenet: properly disable password matching
net: eth: xgene: fix booting with devicetree
bnx2x: Force fundamental reset for EEH recovery
xen-netback: refactor xenvif_handle_frag_list()
...
A couple of driver specific fixes plus a fix for a regression in the
core where the updates to use sysfs group registration were overly
enthusiastic in eliding properties and removed some that had been
previously present.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJU+t5DAAoJECTWi3JdVIfQUmAH/RWw593bjWRnenayjTRF/RYJ
QLayzR/jwPJ7S+occVCpLbUGi4hlDFHePDqbSYQ5VHoqoXxluOW7YH/vSX3gTIj+
46CQOhph223UvwKHj/6KDhCcEynnJCMZIKCnM4friUxXr1tcBAhcEVGR86lWl3ef
xjpUdh4Txf/b3muHayL3aQd0sUTRV7uFlNEn33MgiUmzty3uqx3aSiify2Cj0aCc
TAhEBR8+0BGHOkj0P5/XGzSbdsASi37gbHgXFZ2gekaG/unuZnLQsHaCA81uch4/
6dwU/NjH934NKGEqUcuOCi4lrFHND2vNPWB4q5l2jw+5BUZPpdgW1wXjvyG3+pc=
=+dnv
-----END PGP SIGNATURE-----
Merge tag 'regulator-v4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A couple of driver specific fixes plus a fix for a regression in the
core where the updates to use sysfs group registration were overly
enthusiastic in eliding properties and removed some that had been
previously present"
* tag 'regulator-v4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: Fix regression due to NULL constraints check
regulator: rk808: Set the enable time for LDOs
regulator: da9210: Mask all interrupt sources to deassert interrupt line
A collection of driver specific fixes to which the usual comments about
them being important if you see them mostly apply (except for the
comment fix). The pl022 one is particularly nasty for anyone affected
by it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJU+tr0AAoJECTWi3JdVIfQ4HIH/2p3AR8VJ1NzmqKslFUaC7SQ
CT6iIiV+1gT+Q/2CLtTwY04gVJrmbO85pl4aotefxuCsb8YFGPCEo3f0lYU/3XwK
ZQuC/7LFpWCqQCtSxoat9XQBHoFkWMrFDdsesQJLg9F46bCx/vVUuMaPrTXwSPLG
DA6isoNZgEBJeKAxKhOdwT/nJUrVJhNwEX8fa/vuISnde4ckVuX+34O60V0N0/S2
7hEw3LQFZW0IPsnkmEygd5ATonK/+s7BXLwoAZWJGpZeWB1YsBUiHV7fLunj6gVy
DMbKI3Fp1Yy/q0h6J+DzzbLvQxj0WTAX8EUz8PCh2QYRvUNiKeJdbKLbLUjGZgA=
=Lpqm
-----END PGP SIGNATURE-----
Merge tag 'spi-v4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A collection of driver specific fixes to which the usual comments
about them being important if you see them mostly apply (except for
the comment fix). The pl022 one is particularly nasty for anyone
affected by it"
* tag 'spi-v4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: pl022: Fix race in giveback() leading to driver lock-up
spi: dw-mid: avoid potential NULL dereference
spi: img-spfi: Verify max spfi transfer length
spi: fix a typo in comment.
spi: atmel: Fix interrupt setup for PDC transfers
spi: dw: revisit FIFO size detection again
spi: dw-pci: correct number of chip selects
drivers: spi: ti-qspi: wait for busy bit clear before data write/read
Pull tpm fixes from James Morris:
"fixes for the TPM driver"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
tpm: fix call order in tpm-chip.c
tpm/ibmvtpm: Additional LE support for tpm_ibmvtpm_send
* Fix regression in with omapdss when using i2c displays
* Fix possible null deref in fbmon
* Check kalloc return value in AMBA CLCD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJU/ZY5AAoJEPo9qoy8lh71SQgP/R+w3TCTH4/+bu0D7f7Mebqu
50Jt16eevaNLIXy5Ib4nHAoR6dpkxZO681lkadJHV6uOPSObKPsthLRXbpa95E5G
iX6FeFS4GfS3y9xPDKxKIZBNFjp+w8U2Bkp5V6LAQvlE/oZTQ76eN0nCp25Kb6/h
7mORq9ZdBI4LDG2dgNNZLwXk+n4DX49P5E3SqG2LmbGmZ3gNWyHckU07BB2kgHs0
mCPMoiiheK8RvY64LtXZW1bdAkOYHA+lK4vxkp4bNZUr4ibs3SlUI2eHF4WnRc/6
wYMRnnltyTHdIznBVvnaka9ktLNWJ4eRiA8A7Msd890GL6hqCp+UopfNb/jPgSS8
WbpLVJG4jr2yE5bP6S60GimnN9N8XbJArYHs8gK0iacaFOs96SXRFs2KVM1mwV8P
NnzZKaa+TzNJhCb0ud7zvMXwuNJcEO+TmqnHZRF05h3L3eZ/9LpC8zjXveoJF3GX
3RzI5rn5ZSaXKDjGOKiMaS8AH2aZPcJeJJN6XEozpGMgolSepETS1gL8eXcAl8PE
Wm0Ff4sKZO+/2H9ZYVkI6e7TdHzJQyJPU9Wi9t3iaoEzks3K7QEbCiqQOWPkelFs
RQXZSQ4HP79lsCYlwj91xu/MH/eyNcF/TVV9fIvlkdOcTAJvpGU1ra9PZFxJlWI4
Kfu9afF+MpVAhSd4IxTk
=GHOG
-----END PGP SIGNATURE-----
Merge tag 'fbdev-fixes-4.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux
Pull fbdev fixes from Tomi Valkeinen:
- Fix regression in with omapdss when using i2c displays
- Fix possible null deref in fbmon
- Check kalloc return value in AMBA CLCD
* tag 'fbdev-fixes-4.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
OMAPDSS: fix regression with display sysfs files
video: fbdev: fix possible null dereference
video: ARM CLCD: Add missing error check for devm_kzalloc
Pull cgroup fixes from Tejun Heo:
"The cgroup iteration update two years ago and the recent cpuset
restructuring introduced regressions in subset of cpuset
configurations. Three patches to fix them.
All are marked for -stable"
* 'for-4.0-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
cpuset: Fix cpuset sched_relax_domain_level
cpuset: fix a warning when clearing configured masks in old hierarchy
cpuset: initialize effective masks when clone_children is enabled
Pull libata fixlet from Tejun Heo:
"Speed limiting fix for sata_fsl"
* 'for-4.0-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
sata-fsl: Apply link speed limits
Pull workqueue fix from Tejun Heo:
"One fix patch for a subtle livelock condition which can happen on
PREEMPT_NONE kernels involving two racing cancel_work calls. Whoever
comes in the second has to wait for the previous one to finish. This
was implemented by making the later one block for the same condition
that the former would be (work item completion) and then loop and
retest; unfortunately, depending on the wake up order, the later one
could lock out the former one to finish by busy looping on the cpu.
This is fixed by implementing explicit wait mechanism. Work item
might not belong anywhere at this point and there's remote possibility
of thundering herd problem. I originally tried to use bit_waitqueue
but it didn't work for static work items on modules. It's currently
using single wait queue with filtering wake up function and exclusive
wakeup. If this ever becomes a problem, which is not very likely, we
can try to figure out a way to piggy back on bit_waitqueue"
* 'for-4.0-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
workqueue: fix hang involving racing cancel[_delayed]_work_sync()'s for PREEMPT_NONE
Commit 7d78cbefaa (serial: 8250_dw: add ability to handle
the peripheral clock) introduces handling for a second clk
to 8250_dw.c which is the driver also for LPSS UART. The
second clk forces us to provide identifier (con_id) for the
clkdev we create.
This fixes an issue where 8250_dw.c is getting the same
handler for both clocks.
Fixes: 7d78cbefaa (serial: 8250_dw: add ability to handle the peripheral clock)
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Similar to the reasoning for the previous commit
DIV_ROUND_CLOSEST(parent_rate, rate)
might not be the best integer divisor to get a good approximation for
rate from parent_rate (given the metric for CLK_DIVIDER_ROUND_CLOSEST).
For example assume a parent rate of 1000 Hz and a target rate of 700.
Using DIV_ROUND_CLOSEST the suggested divisor gets calculated to 1
resulting in a target rate of 1000 with a delta of 300 to the desired
rate. With choosing 2 as divisor however the resulting rate is 500 which
is nearer to 700.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
It's an invalid approach to assume that among two divider values
the one nearer the exact divider is the better one.
Assume a parent rate of 1000 Hz, a divider with CLK_DIVIDER_POWER_OF_TWO
and a target rate of 89 Hz. The exact divider is ~ 11.236 so 8 and 16
are the candidates to choose from yielding rates 125 Hz and 62.5 Hz
respectivly. While 8 is nearer to 11.236 than 16 is, the latter is still
the better divider as 62.5 is nearer to 89 than 125 is.
Fixes: 774b514390 (clk: divider: Add round to closest divider)
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
The rate provided at the output of a clk-divider is calculated as:
DIV_ROUND_UP(parent_rate, div)
since commit b11d282dbe (clk: divider: fix rate calculation for
fractional rates). So to yield a rate not bigger than r parent_rate
must be <= r * div.
The effect of choosing a parent rate that is too big as was done before
this patch results in wrongly ruling out good dividers.
Note that this is not a complete fix as __clk_round_rate might return a
value >= its 2nd parameter. Also for dividers with
CLK_DIVIDER_ROUND_CLOSEST set the calculation is not accurate. But this
fixes the test case by Sascha Hauer that uses a chain of three dividers
under a fixed clock.
Fixes: b11d282dbe (clk: divider: fix rate calculation for fractional rates)
Suggested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
In commit c637c10355
("tipc: resolve race problem at unicast message reception") we
introduced a new mechanism for delivering buffers upwards from link
to socket layer.
That code contains a bug in how we handle the new link input queue
during failover. When a link is reset, some of its users may be blocked
because of congestion, and in order to resolve this, we add any pending
wakeup pseudo messages to the link's input queue, and deliver them to
the socket. This misses the case where the other, remaining link also
may have congested users. Currently, the owner node's reference to the
remaining link's input queue is unconditionally overwritten by the
reset link's input queue. This has the effect that wakeup events from
the remaining link may be unduely delayed (but not lost) for a
potentially long period.
We fix this by adding the pending events from the reset link to the
input queue that is currently referenced by the node, whichever one
it is.
This commit should be applied to both net and net-next.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When an interface is deleted from a net namespace the ifindex in the
corresponding entries in PF_PACKET sockets' mclists becomes stale.
This can create inconsistencies if later an interface with the same ifindex
is moved from a different namespace (not that unlikely since ifindexes are
per-namespace).
In particular we saw problems with dev->promiscuity, resulting
in "promiscuity touches roof, set promiscuity failed. promiscuity
feature of device might be broken" warnings and EOVERFLOW failures of
setsockopt(PACKET_ADD_MEMBERSHIP).
This patch deletes the mclist entries for interfaces that are deleted.
Since this now causes setsockopt(PACKET_DROP_MEMBERSHIP) to fail with
EADDRNOTAVAIL if called after the interface is deleted, also make
packet_mc_drop not fail.
Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The configurations are not modified by the driver. Make them 'const' so
that they may be placed in a read-only section.
Signed-off-by: Josh Cartwright <joshc@ni.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJU/Wr5AAoJECte4hHFiupUFfMQAIBg9+GPuBfj60hj47FMrQ3B
93MoIMdYKhkF/cifsWb9xhdOQAMm6ET6DRoJHOxIgEW8twq6R6JFncrB42mA5b/P
kyKVon31PNh2Rdsdn+NaFcuRQSa3Tj7LHeJ53IU82c7V7/WMu3vcBEs4afv7lg+l
bH16iyDMfD3EmzKUl4ul2VqKGGdNISpx8T/y4Spml1ZUWhGAIXh6TSu+E9seZIrP
11fDysK7hRRliXEgzUWX/C6fsNzsWGN8oHFI0s1dIQ4rXPASOFcJpDtUM70+iBmF
arEJXkYD/RrC+olWS8h71Zq4uVVMj6kbUI+w8T8UL9nHA6Rv50Dlq2ZqxsPYeRNB
ZikaGpK2l9XgSxt9YaITMidUC6Q/C5TaALTun/oGZVpF6SY/8zZQKQHkbckFtbDH
ZPD7BRuUFc75wdBV2Qib/nugz1Ado43acZG/Ge0YFYpCIy6d5vtOHCXW5YCafil9
VStmKBN1Vnxnq4HcSBuEsl0qi7rv2RpUF0hEOofzoj++iMFKumjDsXpHcc4U459B
vnjb4LBqpw1ygpzEBBe8gkQa0zpb3vgNI84AKOfKy6FAZTQWXvCOT55oKys/os9G
+KJdF+PjpBVCMvtdKrD8Q0P0zYKmz+Ij57tNOaT1MoqrmpYxcrv7iSYaLrRQp3pd
z55cOGViLtHmB9lPVP5B
=B2aY
-----END PGP SIGNATURE-----
Merge tag 'linux-can-fixes-for-4.0-20150309' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2015-03-09
this is a pull request for net/master for the 4.0 release cycle, it consists of
6 patches:
A patch by Oliver Hartkopp fixes a long outstanding bug in the infrastructure,
which leads to skb_under_panics when CAN interfaces are used by AF_PACKET
sockets e.g. by dhclient. Stephane Grosjean contributes a patch for the
peak_usb driver which adds a missing initialization. Two patches by Ahmed S.
Darwish fix problems in the kvaser_usb driver. Followed by two patches by
myself, updating the MAINTAINERS file
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Some archs (specifically PowerPC), are sensitive with the ordering of
the enabling of the calls to function tracing and setting of the
function to use to be traced.
That is, update_ftrace_function() sets what function the ftrace_caller
trampoline should call. Some archs require this to be set before
calling ftrace_run_update_code().
Another bug was discovered, that ftrace_startup_sysctl() called
ftrace_run_update_code() directly. If the function the ftrace_caller
trampoline changes, then it will not be updated. Instead a call
to ftrace_startup_enable() should be called because it tests to see
if the callback changed since the code was disabled, and will
tell the arch to update appropriately. Most archs do not need this
notification, but PowerPC does.
The problem could be seen by the following commands:
# echo 0 > /proc/sys/kernel/ftrace_enabled
# echo function > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /proc/sys/kernel/ftrace_enabled
# cat /sys/kernel/debug/tracing/trace
The trace will show that function tracing was not active.
Cc: stable@vger.kernel.org # 2.6.27+
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
When ftrace is enabled globally through the proc interface, we must check if
ftrace_graph_active is set. If it is set, then we should also pass the
FTRACE_START_FUNC_RET command to ftrace_run_update_code(). Similarly, when
ftrace is disabled globally through the proc interface, we must check if
ftrace_graph_active is set. If it is set, then we should also pass the
FTRACE_STOP_FUNC_RET command to ftrace_run_update_code().
Consider the following situation.
# echo 0 > /proc/sys/kernel/ftrace_enabled
After this ftrace_enabled = 0.
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
Since ftrace_enabled = 0, ftrace_enable_ftrace_graph_caller() is never
called.
# echo 1 > /proc/sys/kernel/ftrace_enabled
Now ftrace_enabled will be set to true, but still
ftrace_enable_ftrace_graph_caller() will not be called, which is not
desired.
Further if we execute the following after this:
# echo nop > /sys/kernel/debug/tracing/current_tracer
Now since ftrace_enabled is set it will call
ftrace_disable_ftrace_graph_caller(), which causes a kernel warning on
the ARM platform.
On the ARM platform, when ftrace_enable_ftrace_graph_caller() is called,
it checks whether the old instruction is a nop or not. If it's not a nop,
then it returns an error. If it is a nop then it replaces instruction at
that address with a branch to ftrace_graph_caller.
ftrace_disable_ftrace_graph_caller() behaves just the opposite. Therefore,
if generic ftrace code ever calls either ftrace_enable_ftrace_graph_caller()
or ftrace_disable_ftrace_graph_caller() consecutively two times in a row,
then it will return an error, which will cause the generic ftrace code to
raise a warning.
Note, x86 does not have an issue with this because the architecture
specific code for ftrace_enable_ftrace_graph_caller() and
ftrace_disable_ftrace_graph_caller() does not check the previous state,
and calling either of these functions twice in a row has no ill effect.
Link: http://lkml.kernel.org/r/e4fbe64cdac0dd0e86a3bf914b0f83c0b419f146.1425666454.git.panand@redhat.com
Cc: stable@vger.kernel.org # 2.6.31+
Signed-off-by: Pratyush Anand <panand@redhat.com>
[
removed extra if (ftrace_start_up) and defined ftrace_graph_active as 0
if CONFIG_FUNCTION_GRAPH_TRACER is not set.
]
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
When /proc/sys/kernel/ftrace_enabled is set to zero, all function
tracing is disabled. But the records that represent the functions
still hold information about the ftrace_ops that are hooked to them.
ftrace_ops may request "REGS" (have a full set of pt_regs passed to
the callback), or "TRAMP" (the ops has its own trampoline to use).
When the record is updated to represent the state of the ops hooked
to it, it sets "REGS_EN" and/or "TRAMP_EN" to state that the callback
points to the correct trampoline (REGS has its own trampoline).
When ftrace_enabled is set to zero, all ftrace locations are a nop,
so they do not point to any trampoline. But the _EN flags are still
set. This can cause the accounting to go wrong when ftrace_enabled
is cleared and an ops that has a trampoline is registered or unregistered.
For example, the following will cause ftrace to crash:
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
# echo 0 > /proc/sys/kernel/ftrace_enabled
# echo nop > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /proc/sys/kernel/ftrace_enabled
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
As function_graph uses a trampoline, when ftrace_enabled is set to zero
the updates to the record are not done. When enabling function_graph
again, the record will still have the TRAMP_EN flag set, and it will
look for an op that has a trampoline other than the function_graph
ops, and fail to find one.
Cc: stable@vger.kernel.org # 3.17+
Reported-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Stefan Agner