summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-11-24drm: Describe the Rotation property bits.Robert Fekete1-1/+5
Adds clarification of the rotation property bits. I.e. rotation is counter clockwise and that reflects are applied before any rotation. v2: Refer to the define names instead of the property values. Signed-off-by: Robert Fekete <robert.fekete@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-24drm: Remove unused fbdev_list membersLukas Wunner9-10/+0
I noticed that intel_fbdev->our_mode is unused. Introduced by 79e539453b34 ("DRM: i915: add mode setting support"). Then I noticed that intel_fbdev->fbdev_list is unused as well. Introduced by 386516744ba4 ("drm/fb: fix fbdev object model + cleanup properly.") in i915, nouveau and radeon. Subsequently cargo culted to amdgpu, ast, cirrus, qxl, udl, virtio and mgag200. Already removed from the latter with cc59487a05b1 ("drm/mgag200: 'fbdev_list' in 'struct mga_fbdev' is not used"). Remove it from the others. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-24GPU-DRM: Delete unnecessary checks before drm_property_unreference_blob()Markus Elfring2-9/+5
The drm_property_unreference_blob() function tests whether its argument is NULL and then returns immediately. Thus the tests around the calls are not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Link: http://patchwork.freedesktop.org/patch/msgid/563C8B3E.405@users.sourceforge.net Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-24drm/dp: add eDP DPCD backlight control bit definitionsJani Nikula1-0/+36
Cc: Yetunde Adebisi <yetundex.adebisi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-24drm/tegra: Remove local fbdev emulation Kconfig optionArchit Taneja4-23/+11
DRM_TEGRA_FBDEV config is currently used to enable/disable legacy fbdev emulation for the tegra kms driver. Remove this local config option and use the top level DRM_FBDEV_EMULATION config option instead. Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1445933459-5249-4-git-send-email-architt@codeaurora.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-24drm/imx: Remove local fbdev emulation Kconfig optionArchit Taneja2-18/+3
DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev emulation for the imx kms driver. Remove this local config option and use the top level DRM_FBDEV_EMULATION config option where applicable. Using this config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs in certain places. Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1445933459-5249-2-git-send-email-architt@codeaurora.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-24drm/gem: Update/Polish docsDaniel Vetter2-32/+36
A bunch of things have been removed meanwhile and docs not fully brought up to speed. And a few gaps closed where I noticed missing kerneldoc while reading through the overview sections. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445533889-7661-3-git-send-email-daniel.vetter@ffwll.ch Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-24drm: Update GEM refcounting docsDaniel Vetter2-21/+100
I just realized that I've forgotten to update all the gem refcounting docs. For pennance also add pretty docs for the overall drm_gem_object structure, with a few links thrown in fore good. As usually we need to make sure the kerneldoc reference is at most a sect2 for otherwise it won't be listed. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445533889-7661-1-git-send-email-daniel.vetter@ffwll.ch Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-24ARM: dts: vfxxx: Fix dspi[01] spi-num-chipselects.Cory Tusar1-2/+2
Per the Vybrid Reference Manual (section 3.8.6.1), dspi0 has 6 chip select signals associated with it, while dspi1 has only 4. Signed-off-by: Cory Tusar <cory.tusar@pid1solutions.com> Acked-by: Stefan Agner <stefan@agner.ch> Cc: <stable@vger.kernel.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2015-11-24ALSA: hda - Fix headphone noise after Dell XPS 13 resume back from S3Hui Wang1-0/+13
We have a machine Dell XPS 13 with the codec alc256, after resume back from S3, the headphone has noise when play sound. Through comparing with the coeff vaule before and after S3, we found restoring a coeff register will help remove noise. BugLink: https://bugs.launchpad.net/bugs/1519168 Cc: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-11-24blk-merge: warn if figured out segment number is bigger than nr_phys_segmentsMing Lei1-0/+6
We had seen lots of reports of this kind issue, so add one warnning in blk-merge, then it can be triggered easily and avoid to depend on warning/bug from drivers. Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Jens Axboe <axboe@fb.com>
2015-11-24blk-merge: fix blk_bio_segment_splitMing Lei1-3/+19
Commit bdced438acd83a(block: setup bi_phys_segments after splitting) introduces function of computing bio->bi_phys_segments during bio splitting. Unfortunately both bio->bi_seg_front_size and bio->bi_seg_back_size arn't computed, so too many physical segments may be obtained for one request since both the two are used to check if one segment across two bios can be possible. This patch fixes the issue by computing the two variables in blk_bio_segment_split(). Fixes: bdced438acd83a(block: setup bi_phys_segments after splitting) Reported-by: Michael Ellerman <mpe@ellerman.id.au> Reported-by: Mark Salter <msalter@redhat.com> Tested-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Tested-by: Mark Salter <msalter@redhat.com> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Jens Axboe <axboe@fb.com>
2015-11-24block: fix segment splitMing Lei1-2/+2
Inside blk_bio_segment_split(), previous bvec pointer(bvprvp) always points to the iterator local variable, which is obviously wrong, so fix it by pointing to the local variable of 'bvprv'. Fixes: 5014c311baa2b(block: fix bogus compiler warnings in blk-merge.c) Cc: stable@kernel.org #4.3 Reported-by: Michael Ellerman <mpe@ellerman.id.au> Reported-by: Mark Salter <msalter@redhat.com> Tested-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Tested-by: Mark Salter <msalter@redhat.com> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Jens Axboe <axboe@fb.com>
2015-11-24nfs4: limit callback decoding to received bytesBenjamin Coddington3-2/+14
A truncated cb_compound request will cause the client to decode null or data from a previous callback for nfs4.1 backchannel case, or uninitialized data for the nfs4.0 case. This is because the path through svc_process_common() advances the request's iov_base and decrements iov_len without adjusting the overall xdr_buf's len field. That causes xdr_init_decode() to set up the xdr_stream with an incorrect length in nfs4_callback_compound(). Fixing this for the nfs4.1 backchannel case first requires setting the correct iov_len and page_len based on the length of received data in the same manner as the nfs4.0 case. Then the request's xdr_buf length can be adjusted for both cases based upon the remaining iov_len and page_len. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-11-24nfs4: start callback_ident at idr 1Benjamin Coddington1-1/+1
If clp->cl_cb_ident is zero, then nfs_cb_idr_remove_locked() skips removing it when the nfs_client is freed. A decoding or server bug can then find and try to put that first nfs_client which would lead to a crash. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Fixes: d6870312659d ("nfs4client: convert to idr_alloc()") Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-11-24nfs: use sliding delay when LAYOUTGET gets NFS4ERR_DELAYJeff Layton2-1/+2
When LAYOUTGET gets NFS4ERR_DELAY, we currently will wait 15s before retrying the call. That is a _very_ long time, so add a timeout value to struct nfs4_layoutget and pass nfs4_async_handle_error a pointer to it. This allows the RPC engine to use a sliding delay window, instead of a 15s delay. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-11-24NFS4: Cleanup FATTR4_WORD0_FS_LOCATIONS after decoding successKinglong Mee1-0/+1
Commit 1ca843a2d2 "nfs: Fix GETATTR bitmap verification" has check the bitmap after decoding success, but decode_attr_fs_locations forgets cleanup the FATTR4_WORD0_FS_LOCATIONS bits. decode_getfattr_attrs always return -EIO when meeting FS_LOCATIONS now. ls: cannot access /mnt/referal: Input/output error ls: cannot access /mnt/replicas: Input/output error total 32 drwxr-xr-x. 7 root root 8192 Nov 16 20:36 pnfs ??????????? ? ? ? ? ? referal ??????????? ? ? ? ? ? replicas v2: clear the bit earlier Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-11-24NFS: Properly set NFS v4.2 NFSDBG_FACILITYAnna Schumaker1-1/+1
NFS v4.2 operations can work outside of pNFS, so dprintk() output shouldn't be placed under NFSDBG_PNFS. Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-11-24nfs: reduce the amount of ifdefs for v4.2 in nfs4file.cChristoph Hellwig1-20/+7
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-11-24nfs: use btrfs ioctl defintions for cloneChristoph Hellwig2-15/+6
The NFS CLONE_RANGE defintion was wrong and thus never worked. Fix this by simply using the btrfs ioctl defintion. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-11-24nfs: allow intra-file CLONEChristoph Hellwig1-5/+14
Originally CLONE didn't allow for intra-file clones, but we recently updated the spec to support this feature which is also supported by local Linux file systems. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-11-24nfs: offer native ioctls even if CONFIG_COMPAT is setChristoph Hellwig1-3/+0
Without this for example 64-bit binaries on typical amd64 distributions would not be able to use ioctls on NFS. For now this only affects clones. Additionally ->compat_ioctl is defined even for non-compat builds, so get rid of the pointless ifdef. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-11-24nfs: pass on count for CLONE operationsChristoph Hellwig1-0/+1
Currently we pass uninitialized stack garbage in the count parameter. The value is usually large enought to clone whole files and thus let simple tests pass, but it makes the tests for range clones very unhappy. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-11-24vfs: Avoid softlockups with sendfile(2)Jan Kara1-0/+1
The following test program from Dmitry can cause softlockups or RCU stalls as it copies 1GB from tmpfs into eventfd and we don't have any scheduling point at that path in sendfile(2) implementation: int r1 = eventfd(0, 0); int r2 = memfd_create("", 0); unsigned long n = 1<<30; fallocate(r2, 0, 0, n); sendfile(r1, r2, 0, n); Add cond_resched() into __splice_from_pipe() to fix the problem. CC: Dmitry Vyukov <dvyukov@google.com> CC: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-11-24vfs: Make sendfile(2) killable even betterJan Kara1-0/+7
Commit 296291cdd162 (mm: make sendfile(2) killable) fixed an issue where sendfile(2) was doing a lot of tiny writes into a filesystem and thus was unkillable for a long time. However sendfile(2) can be (mis)used to issue lots of writes into arbitrary file descriptor such as evenfd or similar special file descriptors which never hit the standard filesystem write path and thus are still unkillable. E.g. the following example from Dmitry burns CPU for ~16s on my test system without possibility to be killed: int r1 = eventfd(0, 0); int r2 = memfd_create("", 0); unsigned long n = 1<<30; fallocate(r2, 0, 0, n); sendfile(r1, r2, 0, n); There are actually quite a few tests for pending signals in sendfile code however we data to write is always available none of them seems to trigger. So fix the problem by adding a test for pending signal into splice_from_pipe_next() also before the loop waiting for pipe buffers to be available. This should fix all the lockup issues with sendfile of the do-ton-of-tiny-writes nature. CC: stable@vger.kernel.org Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-11-24fix sysvfs symlinksAl Viro1-9/+2
The thing got broken back in 2002 - sysvfs does *not* have inline symlinks; even short ones have bodies stored in the first block of file. sysv_symlink() handles that correctly; unfortunately, attempting to look an existing symlink up will end up confusing them for inline symlinks, and interpret the block number containing the body as the body itself. Nobody has noticed until now, which says something about the level of testing sysvfs gets ;-/ Cc: stable@vger.kernel.org # all of them, not that anyone cared Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-11-24imx: thermal: use CPU temperature grade info for thresholdsTim Harvey1-15/+41
The IMX6Q/IMX6DL SoC's have a 2-bit temperature grade stored in OTP which is valid for all IMX6 SoC's (despite the fact that the IMXSDLRM and IMXSXRM do not document this - this has been proven via tests as well as verified by Freescale FAE). Instead of assuming a fixed 85C for passive cooling threshold and 105C for critical use the thermal grade for these configurations. We will set the critical to maxT - 5C and passive to maxT - 10C. Cc: Anson Huang <b20788@freescale.com> Cc: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Tim Harvey <tharvey@gateworks.com> ---- v3: - rebase against linux-soc-thermal.git - added ack's from Shawn and Jon v2: - remove check for IMX6Q and update comments: The OTP values have been tested on IMX6SOLO, IMX6DUALLITE, and IMX6SX and Freescale FAE has shared data with me that the OTP settings are the same and that the reference manuals will reflect this in their next updates. - set critical to max - 5C - set passive to max - 10C - display max temp in info - do not allow passive to be set above critical Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2015-11-24thermal: fix thermal_zone_bind_cooling_device prototypeArnd Bergmann1-1/+2
When the prototype for thermal_zone_bind_cooling_device changed, the static inline wrapper function was left alone, which in theory can cause build warnings: I have seen this error in the past: drivers/thermal/db8500_thermal.c: In function 'db8500_cdev_bind': drivers/thermal/db8500_thermal.c:78:9: error: too many arguments to function 'thermal_zone_bind_cooling_device' ret = thermal_zone_bind_cooling_device(thermal, i, cdev, while this one no longer shows up, there is no doubt that the prototype is still wrong, so let's just fix it anyway. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 6cd9e9f629f1 ("thermal: of: fix cooling device weights in device tree") Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2015-11-24Revert "thermal: qcom_spmi: allow compile test"Arnd Bergmann1-1/+1
This just caused build errors: warning: (QCOM_SPMI_TEMP_ALARM) selects REGMAP_SPMI which has unmet direct dependencies (SPMI) drivers/built-in.o: In function `regmap_spmi_ext_gather_write': :(.text+0x609b0): undefined reference to `spmi_ext_register_write' :(.text+0x609f0): undefined reference to `spmi_ext_register_writel' While it's generally a good idea to allow compile testing, in this case, it just doesn't work, so reverting the patch that introduced the compile-test variant seems the most appropriate solution. Note that SPMI also has a 'depends on ARCH_QCOM || COMPILE_TEST' statement, so we should be able to enable SPMI on all architectures for compile testing already. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: cb7fb4d34202 ("thermal: qcom_spmi: allow compile test") Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2015-11-24cpufreq: SCPI: Depend on SCPI clk driverPunit Agrawal1-1/+1
The SCPI clk driver registers the virtual cpufreq device that kicks off initialisation of the SCPI cpufreq driver. Also, clk_get() will fail for the cpufreq driver if the SCPI clk driver is missing. Fix this by making the SCPI cpufreq driver explicitly depend on the SCPI clk driver. Fixes: 8def31034d03 (cpufreq: arm_big_little: add SCPI interface driver) Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-24Merge back earlier cpufreq fixes for v4.4.Rafael J. Wysocki2-6/+5
2015-11-24cpufreq: intel_pstate: Fix limits->max_perf rounding errorPrarit Bhargava1-0/+1
A rounding error was found in the calculation of limits->max_perf in intel_pstate_set_policy(), which is used to calculate the max and min pstate values in intel_pstate_get_min_max(). In that code, limits->max_perf is truncated to 2 hex digits such that, for example, 0x169 was incorrectly calculated to 0x16 instead of 0x17. This resulted in the pstate being set one level too low. This patch rounds the value of limits->max_perf up instead of down so that the correct max pstate can be reached. Signed-off-by: Prarit Bhargava <prarit@redhat.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-24cpufreq: intel_pstate: Fix limits->max_policy_pct rounding errorPrarit Bhargava1-1/+2
I have a Intel (6,63) processor with a "marketing" frequency (from /proc/cpuinfo) of 2100MHz, and a max turbo frequency of 2600MHz. I can execute cpupower frequency-set -g powersave --min 1200MHz --max 2100MHz and the max_freq_pct is set to 80. When adding load to the system I noticed that the cpu frequency only reached 2000MHZ and not 2100MHz as expected. This is because limits->max_policy_pct is calculated as 2100 * 100 /2600 = 80.7 and is rounded down to 80 when it should be rounded up to 81. This patch adds a DIV_ROUND_UP() which will return the correct value. Signed-off-by: Prarit Bhargava <prarit@redhat.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-24cpufreq: Always remove sysfs cpuX/cpufreq link on ->remove_dev()Viresh Kumar1-5/+2
Subsys interface's ->remove_dev() is called when the cpufreq driver is unregistering or the CPU is getting physically removed. We keep removing the cpuX/cpufreq link for all CPUs except the last one, which is a mistake as all CPUs contain a link now. Because of this, one CPU from each policy will still contain a link (to an already removed policyX directory), after the cpufreq driver is unregistered. Fix that by removing the link first and then only see if the policy is required to be freed. That will make sure that no links are left out. Fixes: 96bdda61f58b ("cpufreq: create cpu/cpufreq/policyX directories") Reported-and-tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-24cpufreq: CPPC: Initialize and check CPUFreq CPU co-ord type correctlyAshwin Chaugule1-1/+2
The CPU policy struct indicates the co-ordination type for all CPUs of a common freq domain. Initialize it correctly using the CPU specific data gathered from CPPC ACPI lib via acpi_get_psd_map(). The PSD object is optional, so the cpu->shared_type can also be 0. So instead of assuming any value other than SW_ANY(0xFD) is unsupported, explictly check if shared_type is SW_ALL and then bail. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-24Merge tag 'linux-kselftest-4.4-rc3' of ↵Linus Torvalds2-5/+8
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull kselftest fixes from Shuah Khan: "This update consists of one minor documentation fix and a fix to an existing test" * tag 'linux-kselftest-4.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: selftests/seccomp: Get page size from sysconf tools:testing/selftests: fix typo in futex/README
2015-11-23dm thin: fix regression in advertised discard limitsMike Snitzer1-3/+2
When establishing a thin device's discard limits we cannot rely on the underlying thin-pool device's discard capabilities (which are inherited from the thin-pool's underlying data device) given that DM thin devices must provide discard support even when the thin-pool's underlying data device doesn't support discards. Users were exposed to this thin device discard limits regression if their thin-pool's underlying data device does _not_ support discards. This regression caused all upper-layers that called the blkdev_issue_discard() interface to not be able to issue discards to thin devices (because discard_granularity was 0). This regression wasn't caught earlier because the device-mapper-test-suite's extensive 'thin-provisioning' discard tests are only ever performed against thin-pool's with data devices that support discards. Fix is to have thin_io_hints() test the pool's 'discard_enabled' feature rather than inferring whether or not a thin device's discard support should be enabled by looking at the thin-pool's discard_granularity. Fixes: 216076705 ("dm thin: disable discard support for thin devices if pool's is disabled") Reported-by: Mike Gerber <mike@sprachgewalt.de> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org # 4.1+
2015-11-23ARM: dts: keystone: k2l: fix kernel crash when clk_ignore_unused is not in ↵Murali Karicheri2-19/+1
bootargs Currently kernel crash randomly when K2L EVM is booted without clk_ignore_unused in the bootargs. This workaround is not needed on other K2 devices such as K2HK and K2E and with this fix, we can remove the workaround altogether. netcp driver on K2L uses linked ram on OSR (On chip Static RAM) and requires the clock to this peripheral enabled for proper functioning. This is the reason for the kernel crash. So add the clock node to fix this issue. While at it, remove the workaround documentation as well. With the fix applied, clk_summary dump shows the clock to OSR enabled. cat /sys/kernel/debug/clk/clk_summary ------cut-------------- tcp3d-1 0 0 399360000 0 0 tcp3d-0 0 0 399360000 0 0 osr 1 1 399360000 0 0 fftc-0 0 0 399360000 0 0 -----cut---------------- Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
2015-11-23soc: ti: knav_qmss_queue: Fix linking RAM setup for queue managersMichal Morawiec1-1/+1
Configure linking RAM for both queue managers also in case when only linking RAM 0 is specified in device tree. Currently hwqueue driver configures linking RAM(s) to be used cooperatively by the QMs (shared mode). Therefore if both queue managers are used then both must be configured with exactly the same linking RAM info (base address and size) independent of the number of linking RAM(s) specified in the device tree. For proper operation only one linking RAM is required and in most cases this can be internal one as long as it is able to handle the number of descriptors used in the system. Current driver code however skips configuration of second queue manager if second linking RAM is not specified. If the configuration for the QM2 is missing there will be a crash when it tries to push/pop descriptors from its queues. Signed-off-by: Michal Morawiec <michal.1.morawiec.ext@nokia.com> Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
2015-11-23soc: ti: use request_firmware_direct() as acc firmware is optionalMurali Karicheri1-3/+3
When firmware image for PDSP firmware is absent in the file system the kernel boot with ramfs/nfs is stuck for 60 seconds being the the default timeout. request_firmware_direct() is to take care of such optional firmware loading and hence replace the call in the driver with this API. Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
2015-11-23drm/amdgpu: move dependency handling out of atomic section v2Christian König1-27/+44
This way the driver isn't limited in the dependency handling callback. v2: remove extra check in amd_sched_entity_pop_job() Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
2015-11-23drm/amdgpu: optimize scheduler fence handlingChristian König3-14/+55
We only need to wait for jobs to be scheduled when the dependency is from the same scheduler. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
2015-11-23ARC: dw2 unwind: Remove falllback linear search thru FDE entriesVineet Gupta1-33/+4
Fixes STAR 9000953410: "perf callgraph profiling causing RCU stalls" | perf record -g -c 15000 -e cycles /sbin/hackbench | | INFO: rcu_preempt self-detected stall on CPU | 1: (1 GPs behind) idle=609/140000000000002/0 softirq=2914/2915 fqs=603 | Task dump for CPU 1: in-kernel dwarf unwinder has a fast binary lookup and a fallback linear search (which iterates thru each of ~11K entries) thus takes 2 orders of magnitude longer (~3 million cycles vs. 2000). Routines written in hand assembler lack dwarf info (as we don't support assembler CFI pseudo-ops yet) fail the unwinder binary lookup, hit linear search, failing nevertheless in the end. However the linear search is pointless as binary lookup tables are created from it in first place. It is impossible to have binary lookup fail while succeed the linear search. It is pure waste of cycles thus removed by this patch. This manifested as RCU stalls / NMI watchdog splat when running hackbench under perf with callgraph profiling. The triggering condition was perf counter overflowing in routine lacking dwarf info (like memset) leading to patheic 3 million cycle unwinder slow path and by the time it returned new interrupts were already pending (Timer, IPI) and taken rightaway. The original memset didn't make forward progress, system kept accruing more interrupts and more unwinder delayes in a vicious feedback loop, ultimately triggering the NMI diagnostic. Cc: stable@vger.kernel.org Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
2015-11-23powerpc/tm: Check for already reclaimed tasksMichael Neuling1-0/+18
Currently we can hit a scenario where we'll tm_reclaim() twice. This results in a TM bad thing exception because the second reclaim occurs when not in suspend mode. The scenario in which this can happen is the following. We attempt to deliver a signal to userspace. To do this we need obtain the stack pointer to write the signal context. To get this stack pointer we must tm_reclaim() in case we need to use the checkpointed stack pointer (see get_tm_stackpointer()). Normally we'd then return directly to userspace to deliver the signal without going through __switch_to(). Unfortunatley, if at this point we get an error (such as a bad userspace stack pointer), we need to exit the process. The exit will result in a __switch_to(). __switch_to() will attempt to save the process state which results in another tm_reclaim(). This tm_reclaim() now causes a TM Bad Thing exception as this state has already been saved and the processor is no longer in TM suspend mode. Whee! This patch checks the state of the MSR to ensure we are TM suspended before we attempt the tm_reclaim(). If we've already saved the state away, we should no longer be in TM suspend mode. This has the additional advantage of checking for a potential TM Bad Thing exception. Found using syscall fuzzer. Fixes: fb09692e71f1 ("powerpc: Add reclaim and recheckpoint functions for context switching transactional memory processes") Cc: stable@vger.kernel.org # v3.9+ Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-11-23powerpc/tm: Block signal return setting invalid MSR stateMichael Neuling3-5/+14
Currently we allow both the MSR T and S bits to be set by userspace on a signal return. Unfortunately this is a reserved configuration and will cause a TM Bad Thing exception if attempted (via rfid). This patch checks for this case in both the 32 and 64 bit signals code. If both T and S are set, we mark the context as invalid. Found using a syscall fuzzer. Fixes: 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context") Cc: stable@vger.kernel.org # v3.9+ Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-11-23Merge tag 'v4.4-rc2' into drm-intel-next-queuedDaniel Vetter9857-237314/+470664
Linux 4.4-rc2 Backmerge to get at commit 1b0e3a049efe471c399674fd954500ce97438d30 Author: Imre Deak <imre.deak@intel.com> Date: Thu Nov 5 23:04:11 2015 +0200 drm/i915/skl: disable display side power well support for now so that we can proplery re-eanble skl power wells in -next. Conflicts are just adjacent lines changed, except for intel_fbdev.c where we need to interleave the changs. Nothing nefarious. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-11-23watchdog: mtk_wdt: Use MODE_KEY when stopping the watchdogNicolas Boichat1-0/+1
WDT_MODE value need to be or-ed with MODE_KEY when setting watchdog mode. Add it to mtk_wdt_stop function, so that the watchdog can be stopped (e.g. during suspend). Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Acked-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2015-11-23watchdog: Add support for Freescale Layerscape platformsShaohui Xie1-1/+1
Modify watchdog/Kconfig file to support Layerscape platforms. Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by: Hou Zhiqiang <B48286@freescale.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2015-11-23watchdog: tegra: Stop watchdog first if restartingAndrew Chew1-1/+3
If we need to restart the watchdog due to someone changing the timeout interval, stop the watchdog before restarting it. Otherwise, the new timeout doesn't seem to take. Signed-off-by: Andrew Chew <achew@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2015-11-23watchdog: w83977f_wdt: underflow in wdt_set_timeout()Dan Carpenter1-1/+1
"t" is controlled by the user. If "t" is a very large integer then it could lead to a negative "tmrval". We cap the upper bound of "tmrval" but, in the current code, we allow negatives. This is a bug and it causes a static checker warning. Let's make "tmrval" unsigned to avoid this problem. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-01 13:27:56 +0300