We need to hold the rcu_read_lock() when calling rcu_dereference(),
otherwise we can't guarantee that the object being dereferenced still
exists.
Fixes: 39e5d2df ("SUNRPC search xprt switch for sockaddr")
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
The current code doesn't even compile as somehow the inline assembly
can't see the register names defined as ARC_RTC_*
I'm pretty sure It worked when I first got it merged, but the tools were
definitely different then.
So better to write this in "C" anyways.
CC: stable@vger.kernel.org #4.2+
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
The original syscall only used to return errno to indicate if cmpxchg
succeeded. It was not returning the "previous" value which typical cmpxchg
callers are interested in to build their slowpaths or retry loops.
Given user preemption in syscall return path etc, it is not wise to
check this in userspace afterwards, but should be what kernel actually
observed in the syscall.
So change the syscall interface to always return the previous value and
additionally set Z flag to indicate whether operation succeeded or not
(just like ARM implementation when they used to have this syscall)
The flag approach avoids having to put_user errno which is nice given
the use case for this syscall cares mostly about the "previous" value.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
In map_create(), we first find and create the map, then once that
suceeded, we charge it to the user's RLIMIT_MEMLOCK, and then fetch
a new anon fd through anon_inode_getfd(). The problem is, once the
latter fails f.e. due to RLIMIT_NOFILE limit, then we only destruct
the map via map->ops->map_free(), but without uncharging the previously
locked memory first. That means that the user_struct allocation is
leaked as well as the accounted RLIMIT_MEMLOCK memory not released.
Make the label names in the fix consistent with bpf_prog_load().
Fixes: aaac3ba95e ("bpf: charge user for creation of BPF maps and programs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit a6ed3ea65d ("bpf: restore behavior of bpf_map_update_elem")
added an extra per-cpu reserve to the hash table map to restore old
behaviour from pre prealloc times. When non-prealloc is in use for a
map, then problem is that once a hash table extra element has been
linked into the hash-table, and the hash table is destroyed due to
refcount dropping to zero, then htab_map_free() -> delete_all_elements()
will walk the whole hash table and drop all elements via htab_elem_free().
The problem is that the element from the extra reserve is first fed
to the wrong backend allocator and eventually freed twice.
Fixes: a6ed3ea65d ("bpf: restore behavior of bpf_map_update_elem")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
sctp_wait_for_connect() currently already holds the asoc to keep it
alive during the sleep, in case another thread release it. But Andrey
Konovalov and Dmitry Vyukov reported an use-after-free in such
situation.
Problem is that __sctp_connect() doesn't get a ref on the asoc and will
do a read on the asoc after calling sctp_wait_for_connect(), but by then
another thread may have closed it and the _put on sctp_wait_for_connect
will actually release it, causing the use-after-free.
Fix is, instead of doing the read after waiting for the connect, do it
before so, and avoid this issue as the socket is still locked by then.
There should be no issue on returning the asoc id in case of failure as
the application shouldn't trust on that number in such situations
anyway.
This issue doesn't exist in sctp_sendmsg() path.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Reviewed-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Johan Hovold says:
====================
net: fix device reference leaks
This series fixes a number of device reference leaks (and one of_node
leak) due to failure to drop the references taken by bus_find_device()
and friends.
Note that the final two patches have been compile tested only.
v2
- hold reference to cpsw-phy-sel device while accessing private data as
requested by David. Also update the commit message. (patch 1/4)
- add linux-omap on CC where appropriate
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Make sure to drop the reference taken by class_find_device() in
hnae_get_handle() on errors and when later releasing the handle.
Fixes: 6fe6611ff2 ("net: add Hisilicon Network Subsystem...")
Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
Cc: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make sure to drop the references taken by bus_find_device() before
returning from emac_dev_open().
Note that phy_connect still takes a reference to the phy device.
Fixes: 5d69e0076a ("net: davinci_emac: switch to new mdio")
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: linux-omap@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make sure to drop the references taken by of_get_child_by_name() and
bus_find_device() before returning from cpsw_phy_sel().
Note that holding a reference to the cpsw-phy-sel device does not
prevent the devres-managed private data from going away.
Fixes: 5892cd135e ("drivers: net: cpsw-phy-sel: Add new driver...")
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: linux-omap@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make sure to drop the reference taken by bus_find_device_by_name()
before returning from phy_connect() and phy_attach().
Note that both function still take a reference to the phy device
through phy_attach_direct().
Fixes: e13934563d ("[PATCH] PHY Layer fixup")
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
- Fix build failure on compilers without asm goto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJYH+anAAoJELescNyEwWM0fiQIALprhwbhNmqc5q6IVXYJuPw7
kPonaVa1MA6EGANkBwdxD4pbkK2fcsFYsUtiSewP71TwLrRhW/2gPJGUOv3sK6Bq
BXM10O9Meu4Toy45uPofKpRk4yNhJh4WBPPYedzlwitoBUaC4R4sclioqfIOJsvv
z3UI/EXsGpgEuEKQkNHZ5PGUzQ9eLwbhexMJROsdnqVektaDrCSkVtdQNxpMsmve
yy92epfnH9xlk79KrTF1a0lM/SwlQHscua9jsOO+C4Txu6z5s2ltHVtM95Rb5X3a
nmczpMAUesL8g89AdJYOrbSO+dGbCI7ZHhXmcTnWJdRp7g2Hyhei3jNUUwfDJUA=
=GgpB
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fix from Will Deacon:
"It's been pretty quiet on the fixes side of things for us, but Artem
reported a build failure introduced during the merge window that
appears with older GCCs that do not support asm goto. The fix is
bigger than I'd like, but it's a mechnical move of some constants to
break an include dependency between atomic.h and jump_label.h when
!HAVE_JUMP_LABEL.
Summary:
- Fix build failure on compilers without asm goto"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: Fix circular include of asm/lse.h through linux/jump_label.h
Pull HID fixes from Jiri Kosina:
- modprobe-after-rmmod load failure bugfix for intel-ish, from Even Xu
- IRQ probing bugfix for intel-ish, from Srinivas Pandruvada
- attribute parsing fix in hid-sensor, from Ooi, Joyce
- other small misc fixes / quirky device additions
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: sensor: fix attributes in HID sensor interface
HID: intel-ish-hid: request_irq failure
HID: intel-ish-hid: Fix driver reinit failure
HID: intel-ish-hid: Move DMA disable code to new function
HID: intel-ish-hid: consolidate ish wake up operation
HID: usbhid: add ATEN CS962 to list of quirky devices
HID: intel-ish-hid: Fix !CONFIG_PM build warning
HID: sensor-hub: Fix packing of result buffer for feature report
Valleyview appears to be limited to only scanning out from the first 512MiB
of the Global GTT. Lets presume that this behaviour was inherited from the
display block copied from g4x (not Ironlake) and all earlier generations
are similarly affected, though testing suggests different symptoms. For
simplicity, impose that these platforms must scanout from the mappable
region. (For extra simplicity, use HAS_GMCH_DISPLAY even though this
catches Cherryview which does not appear to be limited to the low
aperture for its scanout.)
v2: Use HAS_GMCH_DISPLAY() to more clearly convey my intent about
limiting this workaround to the old style of display engine.
v3: Update changelog to reflect testing by Ville Syrjälä
v4: Include the changes to the comments as well
Reported-by: Luis Botello <luis.botello.ortega@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98036
Fixes: 2efb813d53 ("drm/i915: Fallback to using unmappable memory for scanout")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Akash Goel <akash.goel@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.9-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20161107110128.28762-1-chris@chris-wilson.co.uk
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 767a222e47)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When we split a large object up into chunks for GTT faulting (because we
can't fit the whole object into the aperture) we have to align our cuts
with the fence registers. Each partial VMA must cover a complete set of
tile rows or the offset into each partial VMA is not aligned with the
whole image. Currently we enforce a minimum size on each partial VMA,
but this minimum size itself was not aligned to the tile row causing
distortion.
Reported-by: Andreas Reis <andreas.reis@gmail.com>
Reported-by: Chris Clayton <chris2553@googlemail.com>
Reported-by: Norbert Preining <preining@logic.at>
Tested-by: Norbert Preining <preining@logic.at>
Tested-by: Chris Clayton <chris2553@googlemail.com>
Fixes: 03af84fe7f ("drm/i915: Choose partial chunksize based on tile row size")
Fixes: a61007a83a ("drm/i915: Fix partial GGTT faulting") # enabling patch
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98402
Testcase: igt/gem_mmap_gtt/medium-copy-odd
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.9-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20161107105443.27855-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 0ef723cbce)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
cycling on/off.
Let's apply this work around to GEN9 platforms too, as it fixes the same
issue.
v2: Move drm_device to drm_i915_private conversion
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97907
Cc: stable@vger.kernel.org
Cc: Libin Yang <libin.yang@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1478117601-19122-1-git-send-email-dhinakaran.pandiyan@intel.com
(cherry picked from commit 9c75402418)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
cycling on/off.
From BSpec:
"Display» BDW-SKL» dpr» [Register] DP_TP_CTL [BDW+,EXCLUDE(CHV)]
Workaround : Do not use DisplayPort with CDCLK less than 432 MHz, audio
enabled, port width x4, and link rate HBR2 (5.4 GHz), or else there may
be audio corruption or screen corruption."
Since, some DP configurations (e.g., MST) use port width x4 and HBR2
link rate, let's increase the cdclk to >= 432 MHz to enable audio for those
cases.
v4: Changed commit message
v3: Combine BDW pixel rate adjustments into a function (Jani)
v2: Restrict fix to BDW
Retain the set cdclk across modesets (Ville)
Cc: stable@vger.kernel.org
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1478026080-2925-1-git-send-email-dhinakaran.pandiyan@intel.com
(cherry picked from commit b30ce9e055)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
One of the CI machines began to run into issues with the hpd poller
suddenly waking up in the midst of the late suspend phase. It looks like
this is getting caused by the fact we now deinitialize power wells in
late suspend, which means that intel_hpd_poll_init() gets called in late
suspend causing polling to get re-enabled. So, when deinitializing power
wells on valleyview we now refrain from enabling polling in the midst of
suspend.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98040
Fixes: 19625e85c6 ("drm/i915: Enable polling when we don't have hpd")
Signed-off-by: Lyude <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Saarinen <jani.saarinen@intel.com>
Cc: Petry Latvala <petri.latvala@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477499769-1966-1-git-send-email-lyude@redhat.com
(cherry picked from commit b64b540931)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The VBT provides the platform a way to mix and match the DDI ports vs.
GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose
has no standard GMBUS pin assignment. However, there are machines out
there that use a non-standard mapping for the other ports as well.
Let's start trusting the VBT on this one for all ports on DDI platforms.
I've structured the code such that other platforms could easily start
using this as well, by simply filling in the ddi_port_info. IIRC there
may be CHV system that might actually need this.
v2: Include a commit message, include a debug message during init
Cc: stable@vger.kernel.org
Cc: Maarten Maathuis <madman2003@gmail.com>
Tested-by: Maarten Maathuis <madman2003@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
(cherry picked from commit e4ab73a132)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We recently refactored the Orangefs debugfs code.
The refactor seemed to trigger dan.carpenter@oracle.com's
static tester to find a possible double-free in the code.
While designing the fix we saw a condition under which the
buffer being freed could also be overflowed.
We also realized how to rebuild the related debugfs file's
"contents" (a string) without deleting and re-creating the file.
This fix should eliminate the possible double-free, the
potential overflow and improve code readability.
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
An interrupt may occur right after devm_request_irq() is called and
prior to the spinlock initialization, leading to a kernel oops,
as the interrupt handler uses the spinlock.
In order to prevent this problem, move the spinlock initialization
prior to requesting the interrupts.
Fixes: e4243f13d1 (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In the eMMC 4.51 version of the spec, an EXT_CSD field called
GENERIC_CMD6_TIME[248] was added. This allows cards to specify the maximum
time it may need to move out from its busy state, when a CMD6 command has
been sent.
In cases when the card is compliant to versions < 4.51 of the eMMC spec,
obviously the core needs to use a fall-back value for this timeout, which
currently is set to 10 minutes. This value is completely in the wrong range
and importantly in some cases it causes a card initialization to take more
than 10 minute to complete.
Earlier this scenario was avoided as the mmc core used CMD13 to poll the
card, to find out when it stopped signaling busy. Commit 08573eaf1a
("mmc: mmc: do not use CMD13 to get status after speed mode switch")
changed this behavior.
Instead of reverting that commit, which would cause other issues, let's
instead start by picking a simple solution for the problem, by using a
500ms default generic CMD6 timeout.
The reason for using exactly 500ms, comes from observations that shows it's
quite common for cards to specify 250ms. 500ms is two times that value so
likely it should be enough for most cards.
Cc: <stable@vger.kernel.org> # v4.8+
Fixes: 08573eaf1a ("mmc: mmc: do not use CMD13 to get status after speed
mode switch")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Stephen Boyd <sboyd@codeaurora.org>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
mmc_test_check_result_async() requires that struct mmc_async_req is
contained within struct mmc_test_async_req. Fix the "Commands during
non-blocking write" tests so that is the case.
Fixes: 4bbb9aac9a ("mmc: mmc_test: Add tests for sending commands during transfer")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Ritesh Harjani <riteshh@codeaurora.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
To prevent subsequent commands failing, ensure the cmd and data circuits
are reset after a tuning timeout.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In the busy response case (i.e. !host->data), an unexpected data interrupt
would result in clearing the data command as though it had completed but
without informing the upper layers and thus resulting in a hang. Fix by
only clearing the data command for data interrupts that are expected.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
CMD line reset during an ongoing data transfer can cause the data transfer
to hang. Fix by delaying the reset until the data transfer is finished.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Commit cc7cc02bad ("PCI: Query platform firmware for device power
state") augmented struct pci_platform_pm_ops with a ->get_state hook and
implemented it for acpi_pci_platform_pm, the only pci_platform_pm_ops
existing till v4.7.
However v4.8 introduced another pci_platform_pm_ops for Intel Mobile
Internet Devices with commit 5823d0893e ("x86/platform/intel-mid: Add
Power Management Unit driver"). It is missing the ->get_state hook,
which is fatal since pci_set_platform_pm() enforces its presence. Andy
Shevchenko reports that without the present commit, such a device
"crashes without even a character printed out on serial console and
reboots (since watchdog)".
Retrofit mid_pci_platform_pm with the missing callback to fix the
breakage.
Acked-and-tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Fixes: cc7cc02bad ("PCI: Query platform firmware for device power state")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: http://lkml.kernel.org/r/7c1567d4c49303a4aada94ba16275cbf56b8976b.1477221514.git.lukas@wunner.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This basicly reverts commit e534f3e9 (staging:nvec: Introduce the use of
the managed version of kzalloc). Serio struct should never by managed
because it is refcounted. Doing so will lead to a double free oops on module
remove.
Signed-off-by: Marc Dietrich <marvin24@gmx.de>
Fixes: e534f3e942 ("staging:nvec: Introduce the use of the managed version of kzalloc")
Cc: stable <stable@vger.kernel.org> # 3.15+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 36b30d6138.
This is necessary to detect paz00 (ac100) touchpad properly as one
speaking ETPS/2 protocol. Without it X.org's synaptics driver doesn't
work as the touchpad is detected as an ImPS/2 mouse instead.
Commit ec6184b1c7 changed the way
auto-detection is performed on ports marked as pass through and made the
issue apparent.
A pass through port is an additional PS/2 port used to connect a slave
device to a master device that is using PS/2 to communicate with the
host (so slave's PS/2 communication is tunneled over master's PS/2
link). "Synaptics PS/2 TouchPad Interfacing Guide" describes such a
setup (PS/2 PASS-THROUGH OPTION section).
Since paz00's embedded controller is not connected to a PS/2 port
itself, the PS/2 interface it exposes is not a pass-through one.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Acked-by: Marc Dietrich <marvin24@gmx.de>
Fixes: 36b30d6138 ("staging: nvec: ps2: change serio type to passthrough")
Cc: stable <stable@vger.kernel.org> # 3.4+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This command was sent behind serio's back and the answer to it was
confusing atkbd probe function which lead to the elantech touchpad
getting detected as a keyboard.
To prevent this from happening just let every party do its part of the
job.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Acked-by: Marc Dietrich <marvin24@gmx.de>
Cc: stable <stable@vger.kernel.org> # 3.4+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure to drop the device reference taken by of_find_device_by_node()
before returning from arche_platform_change_state().
Note that this code is expected to be removed, but let's fix up the leak
nonetheless.
Fixes: 886aba558b ("greybus: arche-platform: Export fn to allow...")
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Vaibhav Hiremath <hvaibhav.linux@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
`ni_tio_clock_period_ps()` used to return the clock period in
picoseconds, and had a `BUG()` call for invalid cases. It was changed
to pass the clock period back via a pointer parameter and return an
error for the invalid cases. Unfortunately the code to handle
user-specified clock sources with user-specified clock period is still
returning the clock period the old way, which can lead to the caller not
getting the clock period, or seeing an unexpected error. Fix it by
passing the clock period via the pointer parameter and returning `0`.
Fixes: b42ca86ad6 ("staging: comedi: ni_tio: remove BUG() checks for ni_tio_get_clock_src()")
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: <stable@vger.kernel.org> # 4.7+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If a pin depending on bit 6 in SCU90 is requested for GPIO, the export
will succeed but changes to the GPIO's value will not be accepted by the
hardware. This is because the pinmux driver has misconfigured the SCU by
writing 1 to the reserved bit.
The description of SCU90[6] from the datasheet is 'Reserved, must keep
at value ”0”'. The fix is to switch pinmux from the bit-flipping macro
to explicitly configuring the .enable and .disable values to zero.
The patch has been tested on an AST2500 EVB.
Fixes: 56e57cb6c0 (pinctrl: Add pinctrl-aspeed-g5 driver)
Reported-by: Uma Yadlapati <yadlapat@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Early commit 30ca5cb63c ("staging: sm750fb: change definition of
PANEL_PLANE_TL fields") and 27b047bbe1 ("staging: sm750fb: change
definition of PANEL_PLANE_BR fields") modify the register bit fields
definitions. But the modifications are wrong, because the bit mask of
"bit field 10:0" is not 0xeff, but 0x7ff. The wrong definition bugs
makes display very strange.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: stable <stable@vger.kernel.org> # 4.6+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
variable struct usb_cdc_parsed_header h may be used
uninitialized in acm_probe.
In kernel 4.8.
/* handle quirks deadly to normal probing*/
if (quirks == NO_UNION_NORMAL)
...
goto skip_normal_probe;
}
we bypass call to
cdc_parse_cdc_header(&h, intf, buffer, buflen);
but later use h in
if (h.usb_cdc_country_functional_desc) { /* export the country data */
Signed-off-by: Oliver Neukum <oneukum@suse.com>
CC: stable@vger.kernel.org
Reported-by: Victor Sologoubov <victor0@rambler.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Never seen XHCI auto handoff working on TI and RENESAS cards.
Eventually, we force handoff. This code forces the handoff
unconditionally. It saves 5 seconds boot time for each card.
Signed-off-by: Babu Moger <babu.moger@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This suppresses printing the error message "failed to get phy" in the
kernel log when the error is -EPROBE_DEFER. This prevents usless noise
in the kernel log.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
phy fixes:
*) Add a empty function for phy_reset when CONFIG_GENERIC_PHY is not set
*) change the phy lookup table for da8xx-usb to match it with the name
present in the board configuraion file (used for non-dt boot)
*) Fix incorrect programming sequence in w.r.t deassert of phy_rst
in phy-rockchip-pcie
*) Fix to avoid NULL pointer dereferencing error in sun4i phy
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJYHdt2AAoJEA5ceFyATYLZXGQQAJ3zOzY9bVBGj7HYhyorpY7Q
Ya1EtzMQyZgkUgiMQ4R/+XpWkwE0j3C0Yrvr02AqyLUNDuCQwknzNDqPdVfBiS3/
COx/GUYxiY4WOBnxarNDzzzKN1ttDjCp+f8u+H/Fjkbwr5goB5805HBgUcu/HlKT
hwsU54zfSWjFcuvj5XKL65eR4MeyXbpJ7RCswA81bQ4Hby8tYHt4ByC3Qj3TOsAs
C9nzh3XDVsY+CTQMn036fcmQQDYPTb3l5dSheu5oEvK2RU4iXUp0aM5HPCdh3FwC
PvF54rszGSJbvJaG2+ORmvPhrLlQdJwGDNlTZJNQ8vyTPLQF4riZoglG7GUSOVdU
ZSfdHp1ZB+AYdbirp+zIYCboKvDXR+07fKu2ewWzGHV6WLpVhdI3uOieQPUSwfic
tPdavHzz4h1JtFMnYyI4ab4fjtDaV1G6pnr66GAJ4Zv9zTW6zK60x2aFhkBxFxgf
MfZddxQS1n5RKnyuhkJbuf4NSmcxrZTYOcmdMDO1cncb+JgHUxasKI2a/wfxMdv+
RGQDkhOF0DprDEU4s+AaETVTePeJquU1xfnmisPyupaNd3diSicWCI2r2263QqI8
3Qphgh0tu2hmUhkZZjT5evC/nHePbEFOGASbes8AnH5rKVhIwTLBrOWA5caOoP+G
iZfYv0Q+VJrbcw7krEur
=uTAz
-----END PGP SIGNATURE-----
Merge tag 'phy-for-4.9-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus
Kishon writes:
phy: for 4.9 -rc
phy fixes:
*) Add a empty function for phy_reset when CONFIG_GENERIC_PHY is not set
*) change the phy lookup table for da8xx-usb to match it with the name
present in the board configuraion file (used for non-dt boot)
*) Fix incorrect programming sequence in w.r.t deassert of phy_rst
in phy-rockchip-pcie
*) Fix to avoid NULL pointer dereferencing error in sun4i phy
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Interestingly scale related fixes for accelerometers at both ends of
the range. Obviously more varied devices turning up than we've seen before!
* ad5933
- fix an uninitialized value in a return case that is winding up GCC.
* hid sensors
- missing pm function prevents hid rotations sensors from working on newer
ISH hubs (works by luck on older ones)
- increase of scale precision needed to fix a case where on a yoga 260
the reported scale is 0 (presumably a high precision but very low g sensor).
* st_sensors
- fix an issue seen with the hs3lis331dl where the range is much greater
than previous devices (100's of g) and hence the per bit scale is greater
than 1.
-----BEGIN PGP SIGNATURE-----
iQIuBAABCAAYBQJYH3AgERxqaWMyM0BrZXJuZWwub3JnAAoJEFSFNJnE9BaI7s0P
/RitgKHURPOdUS51Y19slkC/K6S4QaSD7DzH8jRtEmR9iZJjJJwE0ZgCQcmcwd70
tlKZU0PoQcfU6zL0tmW8HX7A48IWfSETLa5Uxv+7lY11u2VLXpMLvMjlJWXYrKPK
FXUUpLacPhER91VlAQpmQKeGuuo8DhGp4tUUeSTCH+RDfKSluN8cOUFAfFMrN6FT
GDuXxKGrLcyKjXW/OvNsimsJyyx8BGrLMCwjJbikTmvHCh2AztCFkgt3rTemU9Xh
fwamxWZu3ezP6+gj554+PNQOe4Z+h3869hzEWu3Oa93ez5cFINm/f258GjfNQP1q
JA57kCwx3nb4SNYHvG7TK154aYQzq5YTkuSEeCz7SUP7WNSWwzBISHJ0ZH++ymIK
smIqXTMg8SKgxBupba5JOyc6lI/5t6sKiB0iROxrWbTDEh4jGFdCwcNL2duarWMx
As4Tgu/3TnhuWA+7MY0FZB4Es0JBdaeXK5D6OKiy0T/6N/m0fzYhX72Fk47LHX4m
WV855PifjjCBqnll4JT49ijXF81E4JZkwl2s2t7K0u43OEjv36L9PfpcKL0xKGx3
XepjqJiC4MPlJj2sKSmOEtq2G+AcGphW/1vbKhLjRva4OphiV78lMKIiSTWi9IaN
LIFVCGe149i1xCH5LQQKDvX+wGMgUsXLl/aCezKd2dLE
=KcFP
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-4.9b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Second set of IIO fixes for the 4.9 cycle.
Interestingly scale related fixes for accelerometers at both ends of
the range. Obviously more varied devices turning up than we've seen before!
* ad5933
- fix an uninitialized value in a return case that is winding up GCC.
* hid sensors
- missing pm function prevents hid rotations sensors from working on newer
ISH hubs (works by luck on older ones)
- increase of scale precision needed to fix a case where on a yoga 260
the reported scale is 0 (presumably a high precision but very low g sensor).
* st_sensors
- fix an issue seen with the hs3lis331dl where the range is much greater
than previous devices (100's of g) and hence the per bit scale is greater
than 1.
Add the "reset" as name of reset controller.
This is for preventing the wrong operation. Even if some SoC has reset
controller, doesn't define "resets" in device-tree.
Then it might be waiting for reset controller and it should be stuck.
Fixes: d6786fefe8 ("mmc: dw_mmc: add reset support to dwmmc host controller")
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add reset-names property for binding dw-mmc controller.
It might be used together with "reset" property.
- Note: It must be "reset" as name.
Fixes: d6786fefe8 ("mmc: dw_mmc: add reset support to dwmmc host controller")
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Fixes for some msm issues
* 'msm-fixes-4.9' of git://people.freedesktop.org/~robclark/linux:
drm/msm: Fix error handling crashes seen when VRAM allocation fails
drm/msm/mdp5: 8x16 actually has 8 mixer stages
drm/msm/mdp5: no scaling support on RGBn pipes for 8x16
drm/msm/mdp5: handle non-fullscreen base plane case
drm/msm: Set CLK_IGNORE_UNUSED flag for PLL clocks
drm/msm/dsi: Queue HPD helper work in attach/detach callbacks
A few more fixes for 4.9.
* 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: add some error handling to amdgpu_init v2
drm/amd: fix scheduler fence teardown order v2
drm/amd/powerplay: don't succeed in getters if fan is missing
drm/amdgpu: make sure ddc_bus is valid in connector unregister
drm/radeon: Fix kernel panic on shutdown
drm/amdgpu: disable runtime pm in certain cases
drm/radeon: disable runtime pm in certain cases
drm/amdgpu: add support for new smc firmware on iceland
drm/amdgpu: add support for new smc firmware on tonga
'blk_mq_alloc_request()' returns an error pointer in case of error, not
NULL. So test it with IS_ERR.
Fixes: fd8383fd88 ("nbd: convert to blkmq")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Jens Axboe <axboe@fb.com>
Starting from 4.9-rc1 kernel, I started noticing some test failures
of sendfile(2) and splice(2) (sendfile0N and splice01 from LTP) when
testing on sub-page block size filesystems (tested both XFS and
ext4), these syscalls start to return EIO in the tests. e.g.
sendfile02 1 TFAIL : sendfile02.c:133: sendfile(2) failed to return expected value, expected: 26, got: -1
sendfile02 2 TFAIL : sendfile02.c:133: sendfile(2) failed to return expected value, expected: 24, got: -1
sendfile02 3 TFAIL : sendfile02.c:133: sendfile(2) failed to return expected value, expected: 22, got: -1
sendfile02 4 TFAIL : sendfile02.c:133: sendfile(2) failed to return expected value, expected: 20, got: -1
This is because that in sub-page block size cases, we don't need the
whole page to be uptodate, only the part we care about is uptodate
is OK (if fs has ->is_partially_uptodate defined). But
page_cache_pipe_buf_confirm() doesn't have the ability to check the
partially-uptodate case, it needs the whole page to be uptodate. So
it returns EIO in this case.
This is a regression introduced by commit 82c156f853 ("switch
generic_file_splice_read() to use of ->read_iter()"). Prior to the
change, generic_file_splice_read() doesn't allow partially-uptodate
page either, so it worked fine.
Fix it by skipping the partially-uptodate check if we're working on
a pipe in do_generic_file_read(), so we read the whole page from
disk as long as the page is not uptodate.
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Anna Schumaker