Pull scheduler fix from Ingo Molnar:
"A single sched/rt corner case fix for RLIMIT_RTIME correctness"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched: Fix RLIMIT_RTTIME when PI-boosting to RT
Pull perf fix from Ingo Molnar:
"A perf kernel side fix for a fuzzer triggered lockup"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf: Fix irq_work 'tail' recursion
Pull locking fix from Ingo Molnar:
"A module unload lockdep race fix"
* 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
lockdep: Fix the module unload key range freeing logic
Pull parsic fixes from Helge Deller:
"One patch from Mikulas fixes a bug on parisc by artifically
incrementing the counter in pmd_free when the kernel tries to free
the preallocated pmd.
Other than that we now prevent that syscalls gets added without
incrementing __NR_Linux_syscalls and fix the initial pmd setup code
if a default page size greater than 4k has been selected"
* 'parisc-4.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Fix pmd code to depend on PT_NLEVELS value, not on CONFIG_64BIT
parisc: mm: don't count preallocated pmds
parisc: Add compile-time check when adding new syscalls
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVFTw+AAoJEGnX8d3iisJeojUP/12ANSkctP29kOjZFkZrav6v
M9qaSR0NqtuxqQ7o8SY4FeA61/vKvy0Sfg5aqfLq1b4YU7FJginyOxZv+d3NPNto
HCS4XVJwFiEmqYx6EgIrCnYmxNQsRTseJEI24/ImHmzvnjufx/JQ9wr0wQVcw/S3
ewxIyf0uyyVJ2UAOMjn2F3ukJYIpteItyT/59ndWluB/+JTHhhJUsIYowP2irU29
EsvEiExNv5d+n35gtxY7GdKEsX5bQc8bTT2UiladcWYIWdb9OoV4+L8MgFh7JHii
vV71D4kdH5bhJsD1D98nm9jFpP6GfPWCY2BMTIhWIYmg+2Zl+cfiaYgIIuBYNG+x
+ahrqB5Nbm+Ux4R7KnIYlXMgDiWMPetkAptUmbod293M/pXPyyQtFhiaB2X9l6Bl
48IUvWYjSp5p8mfhwBXcMItTazrv46HqarHfl3NG0sljRc9BwdPqlumhB1xxsQXg
iauvvD6s6GHRIGapYlINRww9mCaNu5bTcY9cD6AHEc++6Ov/ZYpWnnipmUINNCmL
4yLd+pUQ6QoPuvCHbpzdEvb/eb/LDSbo17nB3aPNn/pPGzICgAXnhY4ET6nzZ3LM
Dc/8FfrYmalYHmjeoWC8CPR/XmrmI7xCkNlF/kre+vCWRLs8Zewl/btxyU48+hho
81HBp3a0QCzCOcFKvzam
=zVXd
-----END PGP SIGNATURE-----
Merge tag 'arc-4.0-fixes-part-2' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
Pull ARC fixes from Vineet Gupta:
"We found some issues with signal handling taking down the system. I
know its late, but these are important and all marked for stable.
ARC signal handling related fixes uncovered during recent testing of
NPTL tools"
* tag 'arc-4.0-fixes-part-2' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARC: signal handling robustify
ARC: SA_SIGINFO ucontext regs off-by-one
Pull selinux bugfix from James Morris.
Fix broken return value.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
selinux: fix sel_write_enforce broken return value
This patch uses iio_trigger_get to increment the reference
count of trigger device, to avoid incorrect assignment.
Can result in a null pointer dereference during removal if the
trigger has been changed before removal.
This patch refers to a similar situation encountered through the
following discussion:
http://www.spinics.net/lists/linux-iio/msg13669.html
Signed-off-by: Darshana Padmadas <darshanapadmadas@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Depending on conversion mode used, the ADC clock (ADCK) needs
to be below a maximum frequency. According to Vybrid's data
sheet this is 20MHz for the low power conversion mode.
The ADC clock is depending on input clock, which is the bus
clock by default. Vybrid SoC are typically clocked at at 400MHz
or 500MHz, which leads to 66MHz or 83MHz bus clock respectively.
Hence, a divider of 8 is required to stay below the specified
maximum clock of 20MHz.
Due to the different bus clock speeds, the resulting sampling
frequency is not static. Hence use the ADC clock and calculate
the actual available sampling frequency dynamically.
This fixes bogous values observed on some 500MHz clocked Vybrid
SoC. The resulting value usually showed Bit 9 being stuck at 1,
or 0, which lead to a value of +/-512.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Fugang Duan <B38611@freescale.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Fixes:
drivers/built-in.o: In function `cc10001_adc_probe':
cc10001_adc.c:(.text+0x412e92): undefined reference to `devm_ioremap_resource'
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The "sdc" node is missing the ranges property, it needs to be treated
as having an empty one otherwise translation fails for its children.
Fixes 746c9e9f92, "of/base: Fix PowerPC address parsing hack"
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Stable <stable@vger.kernel.org> # v3.18+
Three trivial oneliner fixes for HD-audio. Two are device-specific
quirks while one is a generic fix for recent Realtek codecs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVFBixAAoJEGwxgFQ9KSmkvDMQALgan4KGLGHAuNZ0mLU01iA9
9x3P0V33h2uCyjXZJ8ncfxXq3omuQ69Vkk+nUUfzdYw3/mBTy3BWwlf3IVMxUaCQ
UWV36CBf0ZlA2j5CLIqq1axCx4lSv0vmbkoZN3vXh+sLHK/DRqJhqObInpNMRr0R
TLDDM69tvG25dMZbHV6U1Q98HzNlRRPgqxuob3wCaQzg7jyCYbNpk+Q+D70UwOpv
VsqhJSWeoGlRmBQZLpmaJxpO0r5moRCPz/uUlR2XrdBk7PIwoeKIIKOoDcUKCbwR
NlVqldyvRgtRKbjl7HDLyagbHUwf1U6p7WUI27WZY3bBzQl80XUe4eWGmd1gNJqV
0y0akktO5ZjhTWJvxzENC5sQwBVHBYP+cvABYVOMccKixQWPmpGGcpQYEAODliNZ
rwUadJlfZwfxkFNyopMwGfHFhhc3ox/WcTcYh93PucM9jsSpZr2wDeS60s/scyD6
/hEMzTkrxGVzRhPJ6HG4PqHT6oMS6py7FTG35Y4rTjWMvR4UpdakpD17cIqz0Kpj
wO8Ifxgfr+EzmRx+hHYVrLKc1zpHQGrawYYT4nWxqfdSiWmSFC/zdMYYpXrzSv+m
5agjlwVRE65muWp/5VvQLuXwQvDwoM/YMSASNso20qlCOGrQeQF1osrskwtw+7ew
FVC1lX5VEC+gETaa/ql8
=dar7
-----END PGP SIGNATURE-----
Merge tag 'sound-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Three trivial oneliner fixes for HD-audio.
Two are device-specific quirks while one is a generic fix for recent
Realtek codecs"
* tag 'sound-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Add one more node in the EAPD supporting candidate list
ALSA: hda_intel: apply the Seperate stream_tag for Sunrise Point
ALSA: hda - Add dock support for Thinkpad T450s (17aa:5036)
Blacklist queued TRIM on this drive for now.
Reported-by: Stefan Keller <linux-list@zahlenfresser.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
CC: stable@vger.kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>
Micron has released an updated firmware (MU02) for M510/M550/MX100
drives to fix the issues with queued TRIM. Queued TRIM remains broken on
M500 but is working fine on later drives such as M600 and MX200.
Tweak our blacklist to reflect the above.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=71371
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>
Otherwise the VCE firmware needs to be in the first 256MB of VRAM.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dumping is still possible if a ring isn't ready, only when it
isn't allocated at all we need to abort here.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use readb() and memcpy_fromio() accessors instead.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
If the user supplies EDID through firmware or debugfs override, the
driver callbacks are bypassed and the connector ELD does not get
updated, and audio fails. Set ELD for firmware and debugfs EDIDs too.
There should be no harm in gratuitously doing this for non HDMI/DP
connectors, as it's still up to the driver to use the ELD, if any.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82349
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=80691
Reported-by: Emil <emilsvennesson@gmail.com>
Reported-by: Rob Engle <grenoble@gmail.com>
Tested-by: Jolan Luff <jolan@gormsby.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
locks_delete_lock_ctx() is called inside the loop, so we
should use list_for_each_entry_safe.
Fixes: 8634b51f6c (locks: convert lease handling to file_lock_context)
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
dmi_num is a u16, dmi_len is a u32, so this construct:
dmi_num = dmi_len / 4;
would result in an integer overflow for a DMI table larger than
256 kB. I've never see such a large table so far, but SMBIOS 3.0
makes it possible so maybe we'll see such tables in the future.
So instead of faking a structure count when the entry point does
not provide it, adjust the loop condition in dmi_table() to properly
deal with the case where dmi_num is not set.
This bug was introduced with the initial SMBIOS 3.0 support in commit
fc43026278 ("dmi: add support for SMBIOS 3.0 64-bit entry point").
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Cc: <stable@vger.kernel.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Now GPIO syscon driver produces bunch of warnings during the
boot of Kesytone 2 SoCs:
gpio-syscon soc:keystone_dsp_gpio@02620240: can't read the dir register offset!
gpio-syscon soc:keystone_dsp_gpio@2620244: can't read the dir register offset!
This message unintentionally was added using dev_err(), but its
actual log level is debug, because third cell of "ti,syscon-dev" is
optional.
Hence change it to dev_dbg() as it should be.
This patch fixes commit:
5a3e3f8 ("gpio: syscon: retriave syscon node and regs offsets from dt")
Reported-by: Russell King <linux@arm.linux.org.uk>
Tested-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The IMG PDC watchdog driver heartbeat module parameter has no default so
it is initialised to zero. This results in the following warning during
probe:
imgpdc-wdt 2006000.wdt: Initial timeout out of range! setting max timeout
The module parameter description implies that the default value should
be PDC_WDT_DEF_TIMEOUT, which isn't yet used, so initialise it to that.
Also tweak the heartbeat module parameter description for consistency.
Fixes: 93937669e9 ("watchdog: ImgTec PDC Watchdog Timer Driver")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com>
Cc: Naidu Tellapati <Naidu.Tellapati@imgtec.com>
Cc: Jude Abraham <Jude.Abraham@imgtec.com>
Cc: linux-watchdog@vger.kernel.org
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The IMG PDC watchdog probe function calls pdc_wdt_stop() prior to
watchdog_set_drvdata(), causing a NULL pointer dereference when
pdc_wdt_stop() retrieves the struct pdc_wdt_dev pointer using
watchdog_get_drvdata() and reads the register base address through it.
Fix by moving the watchdog_set_drvdata() call earlier, to where various
other pdc_wdt->wdt_dev fields are initialised.
Fixes: 93937669e9 ("watchdog: ImgTec PDC Watchdog Timer Driver")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com>
Cc: Naidu Tellapati <Naidu.Tellapati@imgtec.com>
Cc: Jude Abraham <Jude.Abraham@imgtec.com>
Cc: linux-watchdog@vger.kernel.org
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
"ret" should be signed for the error handling to work correctly. This
doesn't matter much in real life since mtk_wdt_set_timeout() always
succeeds.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
When the receiver was enabled during startup, a character could
have been in the FIFO when the UART get initially used. The
driver configures the (receive) watermark level, and flushes the
FIFO. However, the receive flag (RDRF) could still be set at that
stage (as mentioned in the register description of UARTx_RWFIFO).
This leads to an interrupt which won't be handled properly in
interrupt mode: The receive interrupt function lpuart_rxint checks
the FIFO count, which is 0 at that point (due to the flush
during initialization). The problem does not manifest when using
DMA to receive characters.
Fix this situation by explicitly read the status register, which
leads to clearing of the RDRF flag. Due to the flush just after
the status flag read, a explicit data read is not to required.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Specify transmit FIFO size which might be different depending on
LPUART instance. This makes sure uart_wait_until_sent in serial
core getting called, which in turn waits and checks if the FIFO
is really empty on shutdown by using the tx_empty callback.
Without the call of this callback, the last several characters
might not yet be transmitted when closing the serial port. This
can be reproduced by simply using echo and redirect the output to
a ttyLP device.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Exynos serial ports operate either in a DMA-based or interrupt-based
modes. In DMA-based mode, the UART generates a transfer data request
and a Transmission (Tx) interrupt in interrupt-based mode.
The Tx IRQ is only unmasked in interrupt-based mode and it was done
in s3c24xx_serial_start_tx(). Commit ba019a3e2a ("serial: samsung:
remove redundant interrupt enabling") removed the IRQ enable on that
function since it is enabled when the mode is set in enable_tx_pio().
The problem is that enable_tx_pio() is only called if the port mode
has not been set before but the mode was not cleared on .shutdown().
So if the UART was shutdown and then started up again, the mode set
will remain and the Tx IRQ won't be unmasked.
This caused a hang on at least Exynos5250, Exynos5420 and Exynos5800
when the system is rebooted or powered off.
Fixes: ba019a3e2a ("serial: samsung: remove redundant interrupt enabling")
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull drm refcounting fixes from Dave Airlie:
"Here is the complete set of i915 bug/warn/refcounting fixes"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/i915: Fixup legacy plane->crtc link for initial fb config
drm/i915: Fix atomic state when reusing the firmware fb
drm/i915: Keep ring->active_list and ring->requests_list consistent
drm/i915: Don't try to reference the fb in get_initial_plane_config()
drm: Fixup racy refcounting in plane_force_disable
exposed by the bdi changes that were introduced during the 4.0 merge.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVExTfAAoJEMUj8QotnQNaMMAIAOT0IjDILfxuP/m6DLl+Qq89
SWrKWJrTDc4j8yjaehELH5Vm5Y8W2qlxQAmwritOEm+53HdODSv9I8WpG/6eCEkt
sx+zwQ0wRF0TK6wrqtXe44WU2Zgi9KTj31Y5nTuOAcEqR7S4JHYmbvuzFv/kSO7T
GusA+A1HAp0klGgqxT/mzjz61J/frOCDIXWGFwGPapD+6ZLcHfnCz+Ss4CWhdzvo
xCMXkeoCgvT5dGj5HQQ3RbucaeUIIeYsja2IT2h572GRiUkau+7qtg/YyBvdMnw+
mEcdMcIg+Higc9z3ZSFu/U/QxGwRF/AycXp4zziuiW8KHfRa2BA7+iyQ0odUHlA=
=Ikkj
-----END PGP SIGNATURE-----
Merge tag 'dm-4.0-fix-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fix from Mike Snitzer:
"Fix DM core device cleanup regression -- due to a latent race that was
exposed by the bdi changes that were introduced during the 4.0 merge"
* tag 'dm-4.0-fix-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm: fix add_disk() NULL pointer due to race with free_dev()
This should cover the final warnings in -rc5 with two more backports
from our development branch (drm-intel-next-queued). They're the ones
from Daniel and Damien, with references to the reports.
This is on top of drm-fixes because of the dependency on the two earlier
fixes not yet in Linus' tree.
There's an additional regression fix from Chris.
* tag 'drm-intel-fixes-2015-03-26' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Fixup legacy plane->crtc link for initial fb config
drm/i915: Fix atomic state when reusing the firmware fb
drm/i915: Keep ring->active_list and ring->requests_list consistent
Pull s390 fixes from Martin Schwidefsky:
"A couple of bug fixes for s390.
The ftrace comile fix is quite large for a -rc6 release, but it would
be nice to have it in 4.0"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/smp: reenable smt after resume
s390/mm: limit STACK_RND_MASK for compat tasks
s390/ftrace: fix compile error if CONFIG_KPROBES is disabled
s390/cpum_sf: add diagnostic sampling event only if it is authorized
This is a very similar bug in the load detect code fixed in
commit 9128b040eb
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Mar 3 17:31:21 2015 +0100
drm/i915: Fix modeset state confusion in the load detect code
But this time around it was the initial fb code that forgot to update
the plane->crtc pointer. Otherwise it's the exact same bug, with the
exact same restrains (any set_config call/ioctl that doesn't disable
the pipe papers over the bug for free, so fairly hard to hit in normal
testing). So if you want the full explanation just go read that one
over there - it's rather long ...
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reported-and-tested-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: backported to drm-intel-fixes for v4.0-rc]
Reference: http://mid.gmane.org/CA+5PVA7ChbtJrknqws1qvZcbrg1CW2pQAFkSMURWWgyASRyGXg@mail.gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Right now, we get a warning when taking over the firmware fb:
[drm:drm_atomic_plane_check] FB set but no CRTC
with the following backtrace:
[<ffffffffa010339d>] drm_atomic_check_only+0x35d/0x510 [drm]
[<ffffffffa0103567>] drm_atomic_commit+0x17/0x60 [drm]
[<ffffffffa00a6ccd>] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
[<ffffffffa00f1fed>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
[<ffffffffa00a8a1b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper]
[<ffffffffa00aa969>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[<ffffffffa00aa9e2>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
[<ffffffffa050a71a>] intel_fbdev_set_par+0x1a/0x60 [i915]
[<ffffffff813ad444>] fbcon_init+0x4f4/0x580
That's because we update the plane state with the fb from the firmware, but we
never associate the plane to that CRTC.
We don't quite have the full DRM take over from HW state just yet, so
fake enough of the plane atomic state to pass the checks.
v2: Fix the state on which we set the CRTC in the case we're sharing the
initial fb with another pipe. (Matt)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: backported to drm-intel-fixes for v4.0-rc]
Reference: http://mid.gmane.org/CA+5PVA7yXH=U757w8V=Zj2U1URG4nYNav20NpjtQ4svVueyPNw@mail.gmail.com
Reference: http://lkml.kernel.org/r/CA+55aFweWR=nDzc2Y=rCtL_H8JfdprQiCimN5dwc+TgyD4Bjsg@mail.gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We have a HP machine which use the codec node 0x17 connecting the
internal speaker, and from the node capability, we saw the EAPD,
if we don't set the EAPD on for this node, the internal speaker
can't output any sound.
Cc: <stable@vger.kernel.org>
BugLink: https://bugs.launchpad.net/bugs/1436745
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The sun5i timer is used as the sched-clock on certain systems, and ever
since we started using cpufreq, the cpu clock (that is one of the
timer's clock indirect parent) now changes as well, along with the
actual sched_clock() rate.
This is not accurate and not desirable.
We can safely remove the sun5i sched-clock on those systems, since we
have other reliable sched_clock() sources in the system.
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
[ Improved the changelog. ]
Cc: richard@nod.at
Link: http://lkml.kernel.org/r/1427362029-6511-4-git-send-email-daniel.lezcano@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Fix !CONFIG_HAS_IOMEM related build failures in three clocksource drivers.
The build failures have the pattern of:
drivers/clocksource/sh_cmt.c: In function ‘sh_cmt_map_memory’: drivers/clocksource/sh_cmt.c:920:2:
error: implicit declaration of function ‘ioremap_nocache’ [-Werror=implicit-function-declaration] cmt->mapbase = ioremap_nocache(mem->start, resource_size(mem));
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: maxime.ripard@free-electrons.com
Link: http://lkml.kernel.org/r/1427362029-6511-1-git-send-email-daniel.lezcano@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
If we retire requests last, we may use a later seqno and so clear
the requests lists without clearing the active list, leading to
confusion. Hence we should retire requests first for consistency with
the early return. The order used to be important as the lifecycle for
the object on the active list was determined by request->seqno. However,
the requests themselves are now reference counted removing the
constraint from the order of retirement.
Fixes regression from
commit 1b5a433a4d
Author: John Harrison <John.C.Harrison@Intel.com>
Date: Mon Nov 24 18:49:42 2014 +0000
drm/i915: Convert 'i915_seqno_passed' calls into 'i915_gem_request_completed
'
and a
WARNING: CPU: 0 PID: 1383 at drivers/gpu/drm/i915/i915_gem_evict.c:279 i915_gem_evict_vm+0x10c/0x140()
WARN_ON(!list_empty(&vm->active_list))
Identified by updating WATCH_LISTS:
[drm:i915_verify_lists] *ERROR* blitter ring: active list not empty, but no requests
WARNING: CPU: 0 PID: 681 at drivers/gpu/drm/i915/i915_gem.c:2751 i915_gem_retire_requests_ring+0x149/0x230()
WARN_ON(i915_verify_lists(ring->dev))
Note that this is only a problem in evict_vm where the following happens
after a retire_request has cleaned out all requests, but not all active
bo:
- intel_ring_idle called from i915_gpu_idle notices that no requests are
outstanding and immediately returns.
- i915_gem_retire_requests_ring called from i915_gem_retire_requests also
immediately returns when there's no request, still leaving the bo on the
active list.
- evict_vm hits the WARN_ON(!list_empty(&vm->active_list)) after evicting
all active objects that there's still stuff left that shouldn't be
there.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The total stream number of Sunrise Point's input and output stream
exceeds 15, which will cause some streams do not work because
of the overflow on SDxCTL.STRM field if using the legacy
stream tag allocation method.
This patch uses the new stream tag allocation method by add
the flag AZX_DCAPS_SEPARATE_STREAM_TAG for Skylake platform.
Signed-off-by: Libin Yang <libin.yang@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....
Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.
Reproducer signal handler:
void handle_sig(int signo, siginfo_t *info, void *context)
{
ucontext_t *uc = context;
struct user_regs_struct *regs = &(uc->uc_mcontext.regs);
regs->scratch.status32 = 0;
}
Before the fix, kernel would go off to weeds like below:
--------->8-----------
[ARCLinux]$ ./signal-test
Path: /signal-test
CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000
[ECR ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
[EFA ]: 0x00000010
[BLINK ]: 0x2007c1ee
[ERET ]: 0x10698
[STAT32]: 0x00000000 : <--------
BTA: 0x00010680 SP: 0x5ffe7e48 FP: 0x00000000
LPS: 0x20003c6c LPE: 0x20003c70 LPC: 0x00000000
...
--------->8-----------
Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
The regfile provided to SA_SIGINFO signal handler as ucontext was off by
one due to pt_regs gutter cleanups in 2013.
Before handling signal, user pt_regs are copied onto user_regs_struct and copied
back later. Both structs are binary compatible. This was all fine until
commit 2fa919045b (ARC: pt_regs update #2) which removed the empty stack slot
at top of pt_regs (corresponding to first pad) and made the corresponding
fixup in struct user_regs_struct (the pad in there was moved out of
@scratch - not removed altogether as it is part of ptrace ABI)
struct user_regs_struct {
+ long pad;
struct {
- long pad;
long bta, lp_start, lp_end,....
} scratch;
...
}
This meant that now user_regs_struct was off by 1 reg w.r.t pt_regs and
signal code needs to user_regs_struct.scratch to reflect it as pt_regs,
which is what this commit does.
This problem was hidden for 2 years, because both save/restore, despite
using wrong location, were using the same location. Only an interim
inspection (reproducer below) exposed the issue.
void handle_segv(int signo, siginfo_t *info, void *context)
{
ucontext_t *uc = context;
struct user_regs_struct *regs = &(uc->uc_mcontext.regs);
printf("regs %x %x\n", <=== prints 7 8 (vs. 8 9)
regs->scratch.r8, regs->scratch.r9);
}
int main()
{
struct sigaction sa;
sa.sa_sigaction = handle_segv;
sa.sa_flags = SA_SIGINFO;
sigemptyset(&sa.sa_mask);
sigaction(SIGSEGV, &sa, NULL);
asm volatile(
"mov r7, 7 \n"
"mov r8, 8 \n"
"mov r9, 9 \n"
"mov r10, 10 \n"
:::"r7","r8","r9","r10");
*((unsigned int*)0x10) = 0;
}
Fixes: 2fa919045b "ARC: pt_regs update #2: Remove unused gutter at start of pt_regs"
CC: <stable@vger.kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
With return layout as, (seg is return layout, lo is record layout)
seg->offset <= lo->offset and layout_end(seg) < layout_end(lo),
nfsd should update lo's offset to seg's end,
and,
seg->offset > lo->offset and layout_end(seg) >= layout_end(lo),
nfsd should update lo's end to seg's offset.
Fixes: 9cf514ccfa ("nfsd: implement pNFS operations")
Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
When testing pnfs with nfsd_debug on, nfsd print a negative number
of layout length and foff in nfsd4_block_proc_layoutget as,
"GET: -xxxx:-xxx 2"
Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
alloc_init_lock_stateowner can return an already freed entry if there is
a race to put openowners in the hashtable.
Noticed by inspection after Jeff Layton fixed the same bug for open
owners. Depending on client behavior, this one may be trickier to
trigger in practice.
Fixes: c58c6610ec "nfsd: Protect adding/removing lock owners using client_lock"
Cc: <stable@vger.kernel.org>
Cc: Trond Myklebust <trond.myklebust@primarydata.com>
Acked-by: Jeff Layton <jeff.layton@primarydata.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
alloc_init_open_stateowner can return an already freed entry if there is
a race to put openowners in the hashtable.
In commit 7ffb588086, we changed it so that we allocate and initialize
an openowner, and then check to see if a matching one got stuffed into
the hashtable in the meantime. If it did, then we free the one we just
allocated and take a reference on the one already there. There is a bug
here though. The code will then return the pointer to the one that was
allocated (and has now been freed).
This wasn't evident before as this race almost never occurred. The Linux
kernel client used to serialize requests for a single openowner. That
has changed now with v4.0 kernels, and this race can now easily occur.
Fixes: 7ffb588086
Cc: <stable@vger.kernel.org> # v3.17+
Cc: Trond Myklebust <trond.myklebust@primarydata.com>
Reported-by: Christoph Hellwig <hch@infradead.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Linus Torvalds