aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-01-26perf hists: Fix HISTC_MEM_DCACHELINE width settingJiri Olsa1-0/+2
Set correct width for unresolved mem_dcacheline addr. Signed-off-by: Jiri Olsa <[email protected]> Cc: David Ahern <[email protected]> Cc: Don Zickus <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Fixes: 9b32ba71ba90 ("perf tools: Add dcacheline sort") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2016-01-26perf annotate browser: Fix behaviour of Shift-Tab with nothing focussedMarkus Trippelsdorf1-2/+2
The issue was pointed out by gcc-6's -Wmisleading-indentation. Signed-off-by: Markus Trippelsdorf <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Ben Hutchings <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Peter Zijlstra <[email protected]> Fixes: c97cf42219b7 ("perf top: Live TUI Annotation") Link: http://lkml.kernel.org/r/20151214154403.GB1409@x4 Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2016-01-26perf tests: Remove wrong semicolon in while loop in CQM testMarkus Trippelsdorf1-1/+1
The while loop was spinning. Fix by removing a semicolon. The issue was pointed out by gcc-6's -Wmisleading-indentation. Signed-off-by: Markus Trippelsdorf <[email protected]> Reviewed-by: Matt Fleming <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Ben Hutchings <[email protected]> Cc: Peter Zijlstra <[email protected]> Fixes: 035827e9f2bd ("perf tests: Add Intel CQM test") Link: http://lkml.kernel.org/r/20151214154335.GA1409@x4 Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2016-01-26s390/cio: update measurement characteristicsSebastian Ott2-9/+20
Per channel path measurement characteristics are obtained during channel path registration. However if some properties of a channel path change we don't update the measurement characteristics. Make sure to update the characteristics when we change the properties of a channel path or receive a notification from FW about such a change. Signed-off-by: Sebastian Ott <[email protected]> Reviewed-by: Peter Oberparleiter <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-01-26s390/cio: ensure consistent measurement stateSebastian Ott2-12/+13
Make sure that in all cases where we could not obtain measurement characteristics the associated fields are set to invalid values. Note: without this change the "shared" capability of a channel path for which we could not obtain the measurement characteristics was incorrectly displayed as 0 (not shared). We will now correctly report "unknown" in this case. Signed-off-by: Sebastian Ott <[email protected]> Reviewed-by: Peter Oberparleiter <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-01-26s390/cio: fix measurement characteristics memleakSebastian Ott3-18/+6
Measurement characteristics are allocated during channel path registration but not freed during deregistration. Fix this by embedding these characteristics inside struct channel_path. Signed-off-by: Sebastian Ott <[email protected]> Reviewed-by: Peter Oberparleiter <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-01-26s390/zcrypt: Fix cryptographic device id in kernel messagesIngo Tuchscherer3-20/+24
Currently, on card response failures a combination of card domain and domain id is recorded in the kernel messages. According to the message description only the card id will be recorded. The domain id is not relevant, since the whole card including all domains is set offline. Signed-off-by: Ingo Tuchscherer <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-01-26s390/pci: remove iomap sanity checksSebastian Ott1-9/+4
Since each iomap_entry handles only one bar of one pci function (even when disjunct ranges of a bar are mapped) the sanity check in pci_iomap_range is not needed and can be removed. Also convert the remaining BUG_ONs to WARN_ONs. Signed-off-by: Sebastian Ott <[email protected]> Reviewed-by: Gerald Schaefer <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-01-26s390/pci: set error state for unusable functionsSebastian Ott1-0/+5
We receive special notifications from firmware when an error was detected and a pci function became unusable. Set the error_state accordingly to give device drivers a hint that they don't need to try error recovery. Suggested-by: Alexander Schmidt <[email protected]> Signed-off-by: Sebastian Ott <[email protected]> Reviewed-by: Gerald Schaefer <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-01-26s390/pci: fix bar checkSebastian Ott1-1/+1
Fix the check which bar space we should map to allow available bars only. Signed-off-by: Sebastian Ott <[email protected]> Reviewed-by: Gerald Schaefer <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-01-26s390/pci: resize iomapSebastian Ott1-12/+22
On s390 we need to maintain a mapping between iomem addresses and arch specific function identifiers. Currently the mapping table is created as such that we could span the whole iomem address space. Since we can only map each bar space from each possible function we have an upper bound for the number of mapping entries. This reduces the size of the iomap from 256K to less than 4K (using the defconfig). Signed-off-by: Sebastian Ott <[email protected]> Reviewed-by: Gerald Schaefer <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-01-26s390/pci: improve ZPCI_* macrosSebastian Ott2-7/+10
Most of the constants defined in pci_io.h depend on each other and thus can be calculated. Signed-off-by: Sebastian Ott <[email protected]> Reviewed-by: Gerald Schaefer <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-01-26s390/pci: provide ZPCI_ADDR macroSebastian Ott2-7/+4
Provide and use a ZPCI_ADDR macro as the complement of ZPCI_IDX to get rid of some constants in the code. Signed-off-by: Sebastian Ott <[email protected]> Reviewed-by: Gerald Schaefer <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-01-26s390/pci: adjust IOMAP_MAX_ENTRIESSebastian Ott1-1/+1
ZPCI_IOMAP_MAX_ENTRIES is off by one. Let's adjust this for the sake of correctness. Signed-off-by: Sebastian Ott <[email protected]> Reviewed-by: Gerald Schaefer <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-01-26s390/numa: move numa_init_late() from device to arch_initcallMichael Holzheu1-1/+1
Commit 3e89e1c5ea ("hugetlb: make mm and fs code explicitly non-modular") moves hugetlb_init() from module_init to subsys_initcall. The hugetlb_init()->hugetlb_register_node() code accesses "node->dev.kobj" which is initialized in numa_init_late(). Since numa_init_late() is a device_initcall which is called *after* subsys_initcall the above mentioned patch breaks NUMA on s390. So fix this and move numa_init_late() to arch_initcall. Fixes: 3e89e1c5ea ("hugetlb: make mm and fs code explicitly non-modular") Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Michael Holzheu <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-01-26arm64: defconfig: updates for 4.5Will Deacon1-17/+25
Based on requests, update our defconfig so that: - We don't build any modules - PL031 is enabled (RTC emulated by qemu) - Xen guest support is enabled - The Uniphier built-in I2C controller is enabled - PCI host controller drivers for the various arm64 SoCs are enabled - Device passthrough works on Seattle using SMMU and VFIO - The Hisilicon IRQ controller (mbigen) is enabled Signed-off-by: Will Deacon <[email protected]>
2016-01-26arm64: errata: Add -mpc-relative-literal-loads to build flagsdann frazier1-0/+1
GCC6 (and Linaro's 2015.12 snapshot of GCC5) has a new default that uses adrp/ldr or adrp/add to address literal pools. When CONFIG_ARM64_ERRATUM_843419 is enabled, modules built with this toolchain fail to load: module libahci: unsupported RELA relocation: 275 This patch fixes the problem by passing '-mpc-relative-literal-loads' to the compiler. Cc: [email protected] Fixes: df057cc7b4fa ("arm64: errata: add module build workaround for erratum #843419") BugLink: http://bugs.launchpad.net/bugs/1533009 Acked-by: Ard Biesheuvel <[email protected]> Suggested-by: Christophe Lyon <[email protected]> Signed-off-by: Dann Frazier <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-01-26Eliminate the .eh_frame sections from the aarch64 vmlinux and kernel modulesWilliam Cohen1-0/+1
By default the aarch64 gcc generates .eh_frame sections. Unlike .debug_frame sections, the .eh_frame sections are loaded into memory when the associated code is loaded. On an example kernel being built with this default the .eh_frame section in vmlinux used an extra 1.7MB of memory. The x86 disables the creation of the .eh_frame section. The aarch64 should probably do the same to save some memory. Signed-off-by: William Cohen <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-01-26ALSA: bebob: Use a signed return type for get_formation_indexLucas Tanure1-5/+9
The return type "unsigned int" was used by the get_formation_index function despite of the aspect that it will eventually return a negative error code. So, change to signed int and get index by reference in the parameters. Done with the help of Coccinelle. [Fix the missing braces suggested by Julia Lawall -- tiwai] Signed-off-by: Lucas Tanure <[email protected]> Reviewed-by: Takashi Sakamoto <[email protected]> Tested-by: Takashi Sakamoto <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2016-01-26rtmutex: Make wait_lock irq safeThomas Gleixner2-72/+81
Sasha reported a lockdep splat about a potential deadlock between RCU boosting rtmutex and the posix timer it_lock. CPU0 CPU1 rtmutex_lock(&rcu->rt_mutex) spin_lock(&rcu->rt_mutex.wait_lock) local_irq_disable() spin_lock(&timer->it_lock) spin_lock(&rcu->mutex.wait_lock) --> Interrupt spin_lock(&timer->it_lock) This is caused by the following code sequence on CPU1 rcu_read_lock() x = lookup(); if (x) spin_lock_irqsave(&x->it_lock); rcu_read_unlock(); return x; We could fix that in the posix timer code by keeping rcu read locked across the spinlocked and irq disabled section, but the above sequence is common and there is no reason not to support it. Taking rt_mutex.wait_lock irq safe prevents the deadlock. Reported-by: Sasha Levin <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Paul McKenney <[email protected]>
2016-01-26tools/virtio: add ringtest utilitiesMichael S. Tsirkin8-0/+1123
This adds micro-benchmarks useful for tuning virtio ring layouts. Three layouts are currently implemented: - virtio 0.9 compatible one - an experimental extension bypassing the ring index, polling ring itself instead - an experimental extension bypassing avail and used ring completely Typical use: sh run-on-all.sh perf stat -r 10 --log-fd 1 -- ./ring It doesn't depend on the kernel directly, but it's handy to have as much virtio stuff as possible in one tree. Signed-off-by: Michael S. Tsirkin <[email protected]>
2016-01-26sh: fix smp_store_mb for !SMPMichael S. Tsirkin1-1/+0
sh variant of smp_store_mb() calls xchg() on !SMP which is stronger than implied by both the name and the documentation. commit 90a3ccb0be538a914e6a5c51ae919762261563ad ("sh: define __smp_xxx, fix smp_store_mb for !SMP") was supposed to fix it but left the bug in place. Drop smp_store_mb, so that code in asm-generic/barrier.h will define it correctly depending on CONFIG_SMP. Signed-off-by: Michael S. Tsirkin <[email protected]>
2016-01-26tools/virtio: use virt_xxx barriersMichael S. Tsirkin3-9/+23
Fix build after API changes. Reported-by: Kamal Mostafa <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2016-01-26virtio_pci: fix use after free on releaseMichael S. Tsirkin1-0/+2
KASan detected a use-after-free error in virtio-pci remove code. In virtio_pci_remove(), vp_dev is still used after being freed in unregister_virtio_device() (in virtio_pci_release_dev() more precisely). To fix, keep a reference until cleanup is done. Fixes: 63bd62a08ca4 ("virtio_pci: defer kfree until release callback") Reported-by: Jerome Marchand <[email protected]> Cc: [email protected] Cc: Sasha Levin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Tested-by: Jerome Marchand <[email protected]>
2016-01-26i2c: designware-pci: use IRQF_COND_SUSPEND flagAndy Shevchenko1-1/+2
This is effectively reapplies the commit b0898fdaffb2 ("i2c: designware-pci: use IRQF_COND_SUSPEND flag") after the commit d80d134182ba ("i2c: designware: Move common probe code into i2c_dw_probe()"). Original message as follows. The mentioned flag fixes a warning on Intel Edison board since one of the I2C controller shares IRQ line with watchdog timer. Fixes: d80d134182ba (i2c: designware: Move common probe code into i2c_dw_probe()) Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2016-01-26ALSA: usb-audio: Fix TEAC UD-501/UD-503/NT-503 usb delayGuillaume Fougnies1-1/+13
TEAC UD-501/UD-503/NT-503 fail to switch properly between different rate/format. Similar to 'Playback Design', this patch corrects the invalid clock source error for TEAC products and avoids complete freeze of the usb interface of 503 series. Signed-off-by: Guillaume Fougnies <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2016-01-26i2c: piix4: Fully initialize SB800 before it is registeredJean Delvare1-10/+9
This closes a race window where I2C device drivers attempt to access I2C buses which aren't fully initialized yet. Signed-off-by: Jean Delvare <[email protected]> Tested-by: Christian Fetzer <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2016-01-26i2c: piix4: Fix SB800 lockingJean Delvare1-16/+6
We need a single mutex for all 4 shared SMBus ports on the SB800. A per-port mutex doesn't protect us from concurrent access. In theory the mutex should be per PCI device, however in practice we know that there's only ever a single instance of the device in a given system so we can use a global. Also take the mutex during initialization, as first port may be already in use when second port is initialized. Signed-off-by: Jean Delvare <[email protected]> Tested-by: Christian Fetzer <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> [wsa: made mutex static] Signed-off-by: Wolfram Sang <[email protected]>
2016-01-26drm/amdgpu: don't init fbdev if we don't have any connectorsAlex Deucher1-0/+4
Don't init fbdev if we don't have connectors. E.g., if you have a PX laptop with the displays attached to an IGP with no driver support, you may end up with a blank screen rather than falling back to vesa, etc. Based on a similar radeon patch from Rob Clark. Signed-off-by: Alex Deucher <[email protected]>
2016-01-26drm/radeon: only init fbdev if we have connectorsRob Clark1-2/+4
This fixes an issue that was noticed on an optimus/prime laptop with a kernel that was old enough to not support the integrated intel gfx (which was driving all the outputs), but did have support for the discrete radeon gpu. The end result was not falling back to VESA and leaving the user with a black screen. (Plus it is kind of silly to create an framebuffer device if there are no outputs hooked up to the gpu.) Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2016-01-25Revert "btrfs: clear PF_NOFREEZE in cleaner_kthread()"David Sterba1-1/+0
This reverts commit 696249132158014d594896df3a81390616069c5c. The cleaner thread can block freezing when there's a snapshot cleaning in progress and the other threads get suspended first. From the logs provided by Martin we're waiting for reading extent pages: kernel: PM: Syncing filesystems ... done. kernel: Freezing user space processes ... (elapsed 0.015 seconds) done. kernel: Freezing remaining freezable tasks ... kernel: Freezing of tasks failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0): kernel: btrfs-cleaner D ffff88033dd13bc0 0 152 2 0x00000000 kernel: ffff88032ebc2e00 ffff88032e750000 ffff88032e74fa50 7fffffffffffffff kernel: ffffffff814a58df 0000000000000002 ffffea000934d580 ffffffff814a5451 kernel: 7fffffffffffffff ffffffff814a6e8f 0000000000000000 0000000000000020 kernel: Call Trace: kernel: [<ffffffff814a58df>] ? bit_wait+0x2c/0x2c kernel: [<ffffffff814a5451>] ? schedule+0x6f/0x7c kernel: [<ffffffff814a6e8f>] ? schedule_timeout+0x2f/0xd8 kernel: [<ffffffff81076f94>] ? timekeeping_get_ns+0xa/0x2e kernel: [<ffffffff81077603>] ? ktime_get+0x36/0x44 kernel: [<ffffffff814a4f6c>] ? io_schedule_timeout+0x94/0xf2 kernel: [<ffffffff814a4f6c>] ? io_schedule_timeout+0x94/0xf2 kernel: [<ffffffff814a590b>] ? bit_wait_io+0x2c/0x30 kernel: [<ffffffff814a5694>] ? __wait_on_bit+0x41/0x73 kernel: [<ffffffff8109eba8>] ? wait_on_page_bit+0x6d/0x72 kernel: [<ffffffff8105d718>] ? autoremove_wake_function+0x2a/0x2a kernel: [<ffffffff811a02d7>] ? read_extent_buffer_pages+0x1bd/0x203 kernel: [<ffffffff8117d9e9>] ? free_root_pointers+0x4c/0x4c kernel: [<ffffffff8117e831>] ? btree_read_extent_buffer_pages.constprop.57+0x5a/0xe9 kernel: [<ffffffff8117f4f3>] ? read_tree_block+0x2d/0x45 kernel: [<ffffffff8116782a>] ? read_block_for_search.isra.34+0x22a/0x26b kernel: [<ffffffff811656c3>] ? btrfs_set_path_blocking+0x1e/0x4a kernel: [<ffffffff8116919b>] ? btrfs_search_slot+0x648/0x736 kernel: [<ffffffff81170559>] ? btrfs_lookup_extent_info+0xb7/0x2c7 kernel: [<ffffffff81170ee5>] ? walk_down_proc+0x9c/0x1ae kernel: [<ffffffff81171c9d>] ? walk_down_tree+0x40/0xa4 kernel: [<ffffffff8117375f>] ? btrfs_drop_snapshot+0x2da/0x664 kernel: [<ffffffff8104ff21>] ? finish_task_switch+0x126/0x167 kernel: [<ffffffff811850f8>] ? btrfs_clean_one_deleted_snapshot+0xa6/0xb0 kernel: [<ffffffff8117eaba>] ? cleaner_kthread+0x13e/0x17b kernel: [<ffffffff8117e97c>] ? btrfs_item_end+0x33/0x33 kernel: [<ffffffff8104d256>] ? kthread+0x95/0x9d kernel: [<ffffffff8104d1c1>] ? kthread_parkme+0x16/0x16 kernel: [<ffffffff814a7b5f>] ? ret_from_fork+0x3f/0x70 kernel: [<ffffffff8104d1c1>] ? kthread_parkme+0x16/0x16 As this affects a released kernel (4.4) we need a minimal fix for stable kernels. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=108361 Reported-by: Martin Ziegler <[email protected]> CC: [email protected] # 4.4 CC: Jiri Kosina <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2016-01-25btrfs: async-thread: Fix a use-after-free error for traceQu Wenruo1-1/+1
Parameter of trace_btrfs_work_queued() can be freed in its workqueue. So no one use use that pointer after queue_work(). Fix the user-after-free bug by move the trace line before queue_work(). Reported-by: Dave Jones <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2016-01-25Btrfs: fix race between fsync and lockless direct IO writesFilipe Manana2-11/+39
An fsync, using the fast path, can race with a concurrent lockless direct IO write and end up logging a file extent item that points to an extent that wasn't written to yet. This is because the fast fsync path collects ordered extents into a local list and then collects all the new extent maps to log file extent items based on them, while the direct IO write path creates the new extent map before it creates the corresponding ordered extent (and submitting the respective bio(s)). So fix this by making the direct IO write path create ordered extents before the extent maps and make the fast fsync path collect any new ordered extents after it collects the extent maps. Note that making the fsync handler call inode_dio_wait() (after acquiring the inode's i_mutex) would not work and lead to a deadlock when doing AIO, as through AIO we end up in a path where the fsync handler is called (through dio_aio_complete_work() -> dio_complete() -> vfs_fsync_range()) before the inode's dio counter is decremented (inode_dio_wait() waits for this counter to have a value of zero). Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2016-01-25Merge branch 'fix/fst-sysfs' of ↵Chris Mason6-1/+53
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into for-linus-4.5 Signed-off-by: Chris Mason <[email protected]>
2016-01-25ALSA: compress: Disable GET_CODEC_CAPS ioctl for some architecturesTakashi Iwai1-0/+11
Some architectures like PowerPC can handle the maximum struct size in an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit. This problem was revealed recently by a powerpc change, as it's now treated as a fatal build error. This patch is a stop-gap for that: for architectures with less than 14 bit ioctl struct size, get rid of the handling of the relevant ioctl. We should provide an alternative equivalent ioctl code later, but for now just paper over it. Luckily, the compress API hasn't been used on such architectures, so the impact must be effectively zero. Reviewed-by: Mark Brown <[email protected]> Acked-by: Sudip Mukherjee <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2016-01-25tracing/dma-buf/fence: Fix timeline str value on fence_annotate_wait_onGustavo Padovan1-1/+1
timeline was wrongly assigned with ->get_driver_name(). Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Gustavo Padovan <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
2016-01-25drm/radeon: Ensure radeon bo is unreserved in radeon_gem_va_ioctlMatthew Dawson1-0/+1
Found with lockdep while testing gpu reset. Reviewed-by: Christian König <[email protected]> Signed-off-by: Matthew Dawson <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2016-01-25btrfs: add free space tree to the cow-only listDavid Sterba1-1/+2
Signed-off-by: David Sterba <[email protected]>
2016-01-25btrfs: add free space tree to lockdep classesDavid Sterba1-0/+1
Signed-off-by: David Sterba <[email protected]>
2016-01-25drm/etnaviv: fix failure path if model is zeroRussell King1-2/+2
Fix the failure path to call pm_runtime_mark_last_busy() when failing due to the model field being zero. Acked-by: Christian Gmeiner <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2016-01-25drm/etnaviv: hold object lock while getting pages for coredumpLucas Stach1-0/+2
While all objects that get coredumped have an active IOVA and thus pages already populated, etnaviv_gem_get_pages() still requires the object lock to be held. Signed-off-by: Lucas Stach <[email protected]>
2016-01-25drm/etnaviv: remove owner assignment from platform_driverFabio Estevam1-1/+0
This platform_driver does not need to set an owner as it will be populated by the driver core. Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci. Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2016-01-25USB: option: fix Cinterion AHxx enumerationJohn Ernberg1-1/+1
In certain kernel configurations where the cdc_ether and option drivers are compiled as modules there can occur a race condition in enumeration. This causes the option driver to enumerate the ethernet(wwan) interface as usb-serial interfaces. usb-devices output for the modem: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1e2d ProdID=0055 Rev=00.00 S: Manufacturer=Cinterion S: Product=AHx C: #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=10mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether I: If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether Signed-off-by: John Ernberg <[email protected]> Fixes: 1941138e1c02 ("USB: added support for Cinterion's products...") Cc: stable <[email protected]> # v3.9: 8ff10bdb14a52 Signed-off-by: Johan Hovold <[email protected]>
2016-01-25arm64: Fix an enum typo in mm/dump.cMasanari Iida1-1/+1
This patch fixes a typo in mm/dump.c: "MODUELS_END_NR" should be "MODULES_END_NR". Signed-off-by: Masanari Iida <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-01-25USB: mxu11x0: fix memory leak on usb_serial private dataMathieu OTHACEHE1-0/+20
On nominal execution, private data allocated on port_probe and attach are never freed. Add port_remove and release callbacks to free them respectively. Signed-off-by: Mathieu OTHACEHE <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2016-01-25arm64: Honour !PTE_WRITE in set_pte_at() for kernel mappingsCatalin Marinas1-11/+10
Currently, set_pte_at() only checks the software PTE_WRITE bit for user mappings when it sets or clears the hardware PTE_RDONLY accordingly. The kernel ptes are written directly without any modification, relying solely on the protection bits in macros like PAGE_KERNEL. However, modifying kernel pte attributes via pte_wrprotect() would be ignored by set_pte_at(). Since pte_wrprotect() does not set PTE_RDONLY (it only clears PTE_WRITE), the new permission is not taken into account. This patch changes set_pte_at() to adjust the read-only permission for kernel ptes as well. As a side effect, existing PROT_* definitions used for kernel ioremap*() need to include PTE_DIRTY | PTE_WRITE. (additionally, white space fix for PTE_KERNEL_ROX) Acked-by: Andrey Ryabinin <[email protected]> Tested-by: Ard Biesheuvel <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Reported-by: Ard Biesheuvel <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-01-25arm64: kernel: fix architected PMU registers unconditional accessLorenzo Pieralisi3-2/+19
The Performance Monitors extension is an optional feature of the AArch64 architecture, therefore, in order to access Performance Monitors registers safely, the kernel should detect the architected PMU unit presence through the ID_AA64DFR0_EL1 register PMUVer field before accessing them. This patch implements a guard by reading the ID_AA64DFR0_EL1 register PMUVer field to detect the architected PMU presence and prevent accessing PMU system registers if the Performance Monitors extension is not implemented in the core. Cc: Peter Maydell <[email protected]> Cc: Mark Rutland <[email protected]> Cc: <[email protected]> Fixes: 60792ad349f3 ("arm64: kernel: enforce pmuserenr_el0 initialization and restore") Signed-off-by: Lorenzo Pieralisi <[email protected]> Reported-by: Guenter Roeck <[email protected]> Tested-by: Guenter Roeck <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-01-25arm64: kasan: ensure that the KASAN zero page is mapped read-onlyArd Biesheuvel1-0/+9
When switching from the early KASAN shadow region, which maps the entire shadow space read-write, to the permanent KASAN shadow region, which uses a zero page to shadow regions that are not subject to instrumentation, the lowest level table kasan_zero_pte[] may be reused unmodified, which means that the mappings of the zero page that it contains will still be read-write. So update it explicitly to map the zero page read only when we activate the permanent mapping. Acked-by: Andrey Ryabinin <[email protected]> Acked-by: Catalin Marinas <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-01-25arm64: hide __efistub_ aliases from kallsymsArd Biesheuvel1-15/+25
Commit e8f3010f7326 ("arm64/efi: isolate EFI stub from the kernel proper") isolated the EFI stub code from the kernel proper by prefixing all of its symbols with __efistub_, and selectively allowing access to core kernel symbols from the stub by emitting __efistub_ aliases for functions and variables that the stub can access legally. As an unintended side effect, these aliases are emitted into the kallsyms symbol table, which means they may turn up in backtraces, e.g., ... PC is at __efistub_memset+0x108/0x200 LR is at fixup_init+0x3c/0x48 ... [<ffffff8008328608>] __efistub_memset+0x108/0x200 [<ffffff8008094dcc>] free_initmem+0x2c/0x40 [<ffffff8008645198>] kernel_init+0x20/0xe0 [<ffffff8008085cd0>] ret_from_fork+0x10/0x40 The backtrace in question has nothing to do with the EFI stub, but simply returns one of the several aliases of memset() that have been recorded in the kallsyms table. This is undesirable, since it may suggest to people who are not aware of this that the issue they are seeing is somehow EFI related. So hide the __efistub_ aliases from kallsyms, by emitting them as absolute linker symbols explicitly. The distinction between those and section relative symbols is completely irrelevant to these definitions, and to the final link we are performing when these definitions are being taken into account (the distinction is only relevant to symbols defined inside a section definition when performing a partial link), and so the resulting values are identical to the original ones. Since absolute symbols are ignored by kallsyms, this will result in these values to be omitted from its symbol table. After this patch, the backtrace generated from the same address looks like this: ... PC is at __memset+0x108/0x200 LR is at fixup_init+0x3c/0x48 ... [<ffffff8008328608>] __memset+0x108/0x200 [<ffffff8008094dcc>] free_initmem+0x2c/0x40 [<ffffff8008645198>] kernel_init+0x20/0xe0 [<ffffff8008085cd0>] ret_from_fork+0x10/0x40 Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-01-25USB: serial: ftdi_sio: add support for Yaesu SCU-18 cableGreg Kroah-Hartman2-0/+2
Harald Linden reports that the ftdi_sio driver works properly for the Yaesu SCU-18 cable if the device ids are added to the driver. So let's add them. Reported-by: Harald Linden <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.