aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-02-28ARC: setup cpu possible mask according to possible-cpus dts propertyEugeniy Paltsev1-10/+40
As we have option in u-boot to set CPU mask for running linux, we want to pass information to kernel about CPU cores should be brought up. So we patch kernel dtb in u-boot to set possible-cpus property. This also allows us to have correctly setuped MCIP debug mask. Signed-off-by: Eugeniy Paltsev <[email protected]> Signed-off-by: Vineet Gupta <[email protected]>
2018-02-28ARC: mcip: update MCIP debug mask when the new cpu came onlineEugeniy Paltsev2-5/+34
As of today we use hardcoded MCIP debug mask, so if we launch kernel via debugger and kick fever cores than HW has all cpus hang at the momemt of setup MCIP debug mask. So update MCIP debug mask when the new cpu came online, instead of use hardcoded MCIP debug mask. Signed-off-by: Eugeniy Paltsev <[email protected]> Signed-off-by: Vineet Gupta <[email protected]>
2018-02-28ARC: mcip: halt GFRC counter when ARC cores haltEugeniy Paltsev2-0/+40
In SMP systems, GFRC is used for clocksource. However by default the counter keeps running even when core is halted (say when debugging via a JTAG debugger). This confuses Linux timekeeping and triggers flase RCU stall splat such as below: | [ARCLinux]# while true; do ./shm_open_23-1.run-test ; done | Running with 1000 processes for 1000 objects | hrtimer: interrupt took 485060 ns | | create_cnt: 1000 | Running with 1000 processes for 1000 objects | [ARCLinux]# INFO: rcu_preempt self-detected stall on CPU | 2-...: (1 GPs behind) idle=a01/1/0 softirq=135770/135773 fqs=0 | INFO: rcu_preempt detected stalls on CPUs/tasks: | 0-...: (1 GPs behind) idle=71e/0/0 softirq=135264/135264 fqs=0 | 2-...: (1 GPs behind) idle=a01/1/0 softirq=135770/135773 fqs=0 | 3-...: (1 GPs behind) idle=4e0/0/0 softirq=134304/134304 fqs=0 | (detected by 1, t=13648 jiffies, g=31493, c=31492, q=1) Starting from ARC HS v3.0 it's possible to tie GFRC to state of up-to 4 ARC cores with help of GFRC's CORE register where we set a mask for cores which state we need to rely on. We update cpu mask every time new cpu came online instead of using hardcoded one or using mask generated from "possible_cpus" as we want it set correctly even if we run kernel on HW which has fewer cores than expected (or we launch kernel via debugger and kick fever cores than HW has) Note that GFRC halts when all cores have halted and thus relies on programming of Inter-Core-dEbug register to halt all cores when one halts. Signed-off-by: Alexey Brodkin <[email protected]> Signed-off-by: Eugeniy Paltsev <[email protected]> Signed-off-by: Vineet Gupta <[email protected]> [vgupta: rewrote changelog]
2018-02-28ARCv2: boot log: fix HS48 release numberVineet Gupta1-1/+1
Signed-off-by: Vineet Gupta <[email protected]>
2018-02-28Merge tag 'devicetree-fixes-for-4.16' of ↵Linus Torvalds3-1/+26
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull DeviceTree fixes from Rob Herring: - update i.MX thermal binding example to use current binding, not the deprecated one - move arm-charlcd to auxdisplay/ - fix misspelling of "debounce-interval" * tag 'devicetree-fixes-for-4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: dt-bindings: power: Fix "debounce-interval" property misspelling auxdisplay: Move arm-charlcd binding to correct folder dt-bindings: thermal: imx: update the binding to new method
2018-02-28nvmet: fix PSDT field check in command formatMax Gurtovoy1-3/+6
PSDT field section according to NVM_Express-1.3: "This field specifies whether PRPs or SGLs are used for any data transfer associated with the command. PRPs shall be used for all Admin commands for NVMe over PCIe. SGLs shall be used for all Admin and I/O commands for NVMe over Fabrics. This field shall be set to 01b for NVMe over Fabrics 1.0 implementations. Suggested-by: Idan Burstein <[email protected]> Signed-off-by: Max Gurtovoy <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2018-02-28nvme-multipath: fix sysfs dangerously created linksBaegjae Sung2-14/+13
If multipathing is enabled, each NVMe subsystem creates a head namespace (e.g., nvme0n1) and multiple private namespaces (e.g., nvme0c0n1 and nvme0c1n1) in sysfs. When creating links for private namespaces, links of head namespace are used, so the namespace creation order must be followed (e.g., nvme0n1 -> nvme0c1n1). If the order is not followed, links of sysfs will be incomplete or kernel panic will occur. The kernel panic was: kernel BUG at fs/sysfs/symlink.c:27! Call Trace: nvme_mpath_add_disk_links+0x5d/0x80 [nvme_core] nvme_validate_ns+0x5c2/0x850 [nvme_core] nvme_scan_work+0x1af/0x2d0 [nvme_core] Correct order Context A Context B nvme0n1 nvme0c0n1 nvme0c1n1 Incorrect order Context A Context B nvme0c1n1 nvme0n1 nvme0c0n1 The nvme_mpath_add_disk (for creating head namespace) is called just before the nvme_mpath_add_disk_links (for creating private namespaces). In nvme_mpath_add_disk, the first context acquires the lock of subsystem and creates a head namespace, and other contexts do nothing by checking GENHD_FL_UP of a head namespace after waiting to acquire the lock. We verified the code with or without multipathing using three vendors of dual-port NVMe SSDs. Signed-off-by: Baegjae Sung <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2018-02-28dt-bindings: at24: sort manufacturers alphabeticallyPeter Rosin1-1/+1
Makes them easier to find. Signed-off-by: Peter Rosin <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2018-02-28ALSA: x86: Fix potential crash at error pathTakashi Iwai1-10/+17
When LPE audio driver gets some error at probing, it may lead to a crash because of canceling the pending work in hdmi_lpe_audio_free(), since some of ports might be still not initialized. For assuring the proper free of each port, initialize all ports at the beginning of the probe. Fixes: b4eb0d522fcb ("ALSA: x86: Split snd_intelhad into card and PCM specific structures") Signed-off-by: Takashi Iwai <[email protected]>
2018-02-28ALSA: x86: Fix missing spinlock and mutex initializationsTakashi Iwai1-0/+2
The commit change for supporting the multiple ports moved involved some code shuffling, and there the initializations of spinlock and mutex in snd_intelhad object were dropped mistakenly. This patch adds the missing initializations again for each port. Fixes: b4eb0d522fcb ("ALSA: x86: Split snd_intelhad into card and PCM specific structures") Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-02-28ALSA: control: Fix memory corruption risk in snd_ctl_elem_readRichard Fitzgerald1-1/+1
The patch "ALSA: control: code refactoring for ELEM_READ/ELEM_WRITE operations" introduced a potential for kernel memory corruption due to an incorrect if statement allowing non-readable controls to fall through and call the get function. For TLV controls a driver can omit SNDRV_CTL_ELEM_ACCESS_READ to ensure that only the TLV get function can be called. Instead the normal get() can be invoked unexpectedly and as the driver expects that this will only be called for controls <= 512 bytes, potentially try to copy >512 bytes into the 512 byte return array, so corrupting kernel memory. The problem is an attempt to refactor the snd_ctl_elem_read function to invert the logic so that it conditionally aborted if the control is unreadable instead of conditionally executing. But the if statement wasn't inverted correctly. The correct inversion of if (a && !b) is if (!a || b) Fixes: becf9e5d553c2 ("ALSA: control: code refactoring for ELEM_READ/ELEM_WRITE operations") Signed-off-by: Richard Fitzgerald <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-02-28Merge branch 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie8-25/+24
into drm-fixes - Powerplay fixes for cards with no displays attached - Couple of DC fixes - radeon workaround for PPC64 * 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE drm/amd/display: VGA black screen from s3 when attached to hook drm/amdgpu: Unify the dm resume calls into one drm/amdgpu: Add a missing lock for drm_mm_takedown Revert "drm/radeon/pm: autoswitch power state when in balanced mode" drm/amd/powerplay/smu7: allow mclk switching with no displays drm/amd/powerplay/vega10: allow mclk switching with no displays
2018-02-27ARM: dts: bcm283x: Move arm-pmu out of soc nodeStefan Wahren2-8/+8
The ARM PMU doesn't have a reg address, so fix the following DTC warning (requires W=1): Node /soc/arm-pmu missing or empty reg/ranges property Signed-off-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Florian Fainelli <[email protected]>
2018-02-27ARM: dts: bcm283x: Fix unit address of local_intcStefan Wahren2-2/+2
This patch fixes the following DTC warning (requires W=1): Node /soc/local_intc simple-bus unit address format error, expected "40000000" Signed-off-by: Stefan Wahren <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Florian Fainelli <[email protected]>
2018-02-27ARM: dts: NSP: Fix amount of RAM on BCM958625HRFlorian Fainelli1-1/+1
Jon attempted to fix the amount of RAM on the BCM958625HR in commit c53beb47f621 ("ARM: dts: NSP: Correct RAM amount for BCM958625HR board") but it seems like we tripped over some poorly documented schematics. The top-level page of the schematics says the board has 2GB, but when you end-up scrolling to page 6, you see two chips of 4GBit (512MB) but what the bootloader really initializes only 512MB, any attempt to use more than that results in data aborts. Fix this again back to 512MB. Fixes: c53beb47f621 ("ARM: dts: NSP: Correct RAM amount for BCM958625HR board") Acked-by: Jon Mason <[email protected]> Signed-off-by: Florian Fainelli <[email protected]>
2018-02-27nbd: fix return value in error handling pathGustavo A. R. Silva1-1/+1
It seems that the proper value to return in this particular case is the one contained into variable new_index instead of ret. Addresses-Coverity-ID: 1465148 ("Copy-paste error") Fixes: e46c7287b1c2 ("nbd: add a basic netlink interface") Reviewed-by: Omar Sandoval <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-02-27Merge branch 'fixes-v4.16-rc4' of ↵Linus Torvalds1-9/+1
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull seccomp fix from James Morris: "This disables the seccomp samples when cross compiling. We've seen too many build issues here, so it's best to just disable it, especially since they're just the samples" * 'fixes-v4.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: samples/seccomp: do not compile when cross compiled
2018-02-27Merge tag 'seccomp-v4.16-rc4' of ↵James Morris1-9/+1
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into fixes-v4.16-rc4 - do not build samples when cross compiling (Michal Hocko) From Kees: "This disables the seccomp samples when cross compiling. We're seen too many build issues here, so it's best to just disable it, especially since they're just the samples."
2018-02-27bcache: fix kcrashes with fio in RAID5 backend devTang Junhui1-1/+1
Kernel crashed when run fio in a RAID5 backend bcache device, the call trace is bellow: [ 440.012034] kernel BUG at block/blk-ioc.c:146! [ 440.012696] invalid opcode: 0000 [#1] SMP NOPTI [ 440.026537] CPU: 2 PID: 2205 Comm: md127_raid5 Not tainted 4.15.0 #8 [ 440.027441] Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 07/16 /2015 [ 440.028615] RIP: 0010:put_io_context+0x8b/0x90 [ 440.029246] RSP: 0018:ffffa8c882b43af8 EFLAGS: 00010246 [ 440.029990] RAX: 0000000000000000 RBX: ffffa8c88294fca0 RCX: 0000000000 0f4240 [ 440.031006] RDX: 0000000000000004 RSI: 0000000000000286 RDI: ffffa8c882 94fca0 [ 440.032030] RBP: ffffa8c882b43b10 R08: 0000000000000003 R09: ffff949cb8 0c1700 [ 440.033206] R10: 0000000000000104 R11: 000000000000b71c R12: 00000000000 01000 [ 440.034222] R13: 0000000000000000 R14: ffff949cad84db70 R15: ffff949cb11 bd1e0 [ 440.035239] FS: 0000000000000000(0000) GS:ffff949cba280000(0000) knlGS: 0000000000000000 [ 440.060190] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 440.084967] CR2: 00007ff0493ef000 CR3: 00000002f1e0a002 CR4: 00000000001 606e0 [ 440.110498] Call Trace: [ 440.135443] bio_disassociate_task+0x1b/0x60 [ 440.160355] bio_free+0x1b/0x60 [ 440.184666] bio_put+0x23/0x30 [ 440.208272] search_free+0x23/0x40 [bcache] [ 440.231448] cached_dev_write_complete+0x31/0x70 [bcache] [ 440.254468] closure_put+0xb6/0xd0 [bcache] [ 440.277087] request_endio+0x30/0x40 [bcache] [ 440.298703] bio_endio+0xa1/0x120 [ 440.319644] handle_stripe+0x418/0x2270 [raid456] [ 440.340614] ? load_balance+0x17b/0x9c0 [ 440.360506] handle_active_stripes.isra.58+0x387/0x5a0 [raid456] [ 440.380675] ? __release_stripe+0x15/0x20 [raid456] [ 440.400132] raid5d+0x3ed/0x5d0 [raid456] [ 440.419193] ? schedule+0x36/0x80 [ 440.437932] ? schedule_timeout+0x1d2/0x2f0 [ 440.456136] md_thread+0x122/0x150 [ 440.473687] ? wait_woken+0x80/0x80 [ 440.491411] kthread+0x102/0x140 [ 440.508636] ? find_pers+0x70/0x70 [ 440.524927] ? kthread_associate_blkcg+0xa0/0xa0 [ 440.541791] ret_from_fork+0x35/0x40 [ 440.558020] Code: c2 48 00 5b 41 5c 41 5d 5d c3 48 89 c6 4c 89 e7 e8 bb c2 48 00 48 8b 3d bc 36 4b 01 48 89 de e8 7c f7 e0 ff 5b 41 5c 41 5d 5d c3 <0f> 0b 0f 1f 00 0f 1f 44 00 00 55 48 8d 47 b8 48 89 e5 41 57 41 [ 440.610020] RIP: put_io_context+0x8b/0x90 RSP: ffffa8c882b43af8 [ 440.628575] ---[ end trace a1fd79d85643a73e ]-- All the crash issue happened when a bypass IO coming, in such scenario s->iop.bio is pointed to the s->orig_bio. In search_free(), it finishes the s->orig_bio by calling bio_complete(), and after that, s->iop.bio became invalid, then kernel would crash when calling bio_put(). Maybe its upper layer's faulty, since bio should not be freed before we calling bio_put(), but we'd better calling bio_put() first before calling bio_complete() to notify upper layer ending this bio. This patch moves bio_complete() under bio_put() to avoid kernel crash. [mlyle: fixed commit subject for character limits] Reported-by: Matthias Ferdinand <[email protected]> Tested-by: Matthias Ferdinand <[email protected]> Signed-off-by: Tang Junhui <[email protected]> Reviewed-by: Michael Lyle <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-02-27bcache: correct flash only vols (check all uuids)Coly Li1-1/+1
Commit 2831231d4c3f ("bcache: reduce cache_set devices iteration by devices_max_used") adds c->devices_max_used to reduce iteration of c->uuids elements, this value is updated in bcache_device_attach(). But for flash only volume, when calling flash_devs_run(), the function bcache_device_attach() is not called yet and c->devices_max_used is not updated. The unexpected result is, the flash only volume won't be run by flash_devs_run(). This patch fixes the issue by iterate all c->uuids elements in flash_devs_run(). c->devices_max_used will be updated properly when bcache_device_attach() gets called. [mlyle: commit subject edited for character limit] Fixes: 2831231d4c3f ("bcache: reduce cache_set devices iteration by devices_max_used") Reported-by: Tang Junhui <[email protected]> Signed-off-by: Coly Li <[email protected]> Reviewed-by: Michael Lyle <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-02-27Merge branch 'fixes-v4.16-rc4' of ↵Linus Torvalds6-8/+22
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull tpm fixes from James Morris: "Bugfixes for TPM, from Jeremy Boone, via Jarkko Sakkinen" * 'fixes-v4.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: tpm: fix potential buffer overruns caused by bit glitches on the bus tpm: st33zp24: fix potential buffer overruns caused by bit glitches on the bus tpm_i2c_infineon: fix potential buffer overruns caused by bit glitches on the bus tpm_i2c_nuvoton: fix potential buffer overruns caused by bit glitches on the bus tpm_tis: fix potential buffer overruns caused by bit glitches on the bus
2018-02-27cpufreq: s3c24xx: Fix broken s3c_cpufreq_init()Viresh Kumar1-1/+7
commit a307a1e6bc0d "cpufreq: s3c: use cpufreq_generic_init()" accidentally broke cpufreq on s3c2410 and s3c2412. These two platforms don't have a CPU frequency table and used to skip calling cpufreq_table_validate_and_show() for them. But with the above commit, we started calling it unconditionally and that will eventually fail as the frequency table pointer is NULL. Fix this by calling cpufreq_table_validate_and_show() conditionally again. Fixes: a307a1e6bc0d "cpufreq: s3c: use cpufreq_generic_init()" Cc: 3.13+ <[email protected]> # v3.13+ Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-27mmc: core: Avoid hanging to claim host for mmc via some nested callsUlf Hansson1-4/+0
As the block layer, since the conversion to blkmq, claims the host using a context, a following nested call to mmc_claim_host(), which isn't using a context, may hang. Calling mmc_interrupt_hpi() and mmc_read_bkops_status() via the mmc block layer, may suffer from this problem, as these functions are calling mmc_claim|release_host(). Let's fix the problem by removing the calls to mmc_claim|release_host() from the above mentioned functions and instead make the callers responsible of claiming/releasing the host. As a matter of fact, the existing callers already deals with it. Fixes: 81196976ed94 ("mmc: block: Add blk-mq support") Reported-by: Dmitry Osipenko <[email protected]> Suggested-by: Adrian Hunter <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Acked-by: Adrian Hunter <[email protected]> Reviewed-by: Shawn Lin <[email protected]>
2018-02-27mmc: dw_mmc: Avoid accessing registers in runtime suspended stateShawn Lin1-0/+4
cat /sys/kernel/debug/mmc0/regs will hang up the system since it's in runtime suspended state, so the genpd and biu_clk is off. This patch fixes this problem by calling pm_runtime_get_sync to wake it up before reading the registers. Fixes: e9ed8835e990 ("mmc: dw_mmc: add runtime PM callback") Cc: <[email protected]> Signed-off-by: Shawn Lin <[email protected]> Reviewed-by: Jaehoon Chung <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2018-02-27mmc: dw_mmc: Fix out-of-bounds access for slot's capsShawn Lin6-1/+14
Add num_caps field for dw_mci_drv_data to validate the controller id from DT alias and non-DT ways. Reported-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Shawn Lin <[email protected]> Fixes: 800d78bfccb3 ("mmc: dw_mmc: add support for implementation specific callbacks") Cc: <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2018-02-27mmc: dw_mmc: Factor out dw_mci_init_slot_capsShawn Lin1-30/+43
Factor out dw_mci_init_slot_caps to consolidate parsing all differents types of capabilities from host contrllers. No functional change intended. Signed-off-by: Shawn Lin <[email protected]> Fixes: 800d78bfccb3 ("mmc: dw_mmc: add support for implementation specific callbacks") Cc: <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2018-02-27mmc: dw_mmc-k3: Fix out-of-bounds access through DT aliasGeert Uytterhoeven1-0/+3
The hs_timing_cfg[] array is indexed using a value derived from the "mshcN" alias in DT, which may lead to an out-of-bounds access. Fix this by adding a range check. Fixes: 361c7fe9b02eee7e ("mmc: dw_mmc-k3: add sd support for hi3660") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Shawn Lin <[email protected]> Cc: <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2018-02-27printk: Wake klogd when passing console_lock ownerPetr Mladek1-1/+2
wake_klogd is a local variable in console_unlock(). The information is lost when the console_lock owner using the busy wait added by the commit dbdda842fe96f8932 ("printk: Add console owner and waiter logic to load balance console writes"). The following race is possible: CPU0 CPU1 console_unlock() for (;;) /* calling console for last message */ printk() log_store() log_next_seq++; /* see new message */ if (seen_seq != log_next_seq) { wake_klogd = true; seen_seq = log_next_seq; } console_lock_spinning_enable(); if (console_trylock_spinning()) /* spinning */ if (console_lock_spinning_disable_and_check()) { printk_safe_exit_irqrestore(flags); return; console_unlock() if (seen_seq != log_next_seq) { /* already seen */ /* nothing to do */ Result: Nobody would wakeup klogd. One solution would be to make a global variable from wake_klogd. But then we would need to manipulate it under a lock or so. This patch wakes klogd also when console_lock is passed to the spinning waiter. It looks like the right way to go. Also userspace should have a chance to see and store any "flood" of messages. Note that the very late klogd wake up was a historic solution. It made sense on single CPU systems or when sys_syslog() operations were synchronized using the big kernel lock like in v2.1.113. But it is questionable these days. Fixes: dbdda842fe96f8932 ("printk: Add console owner and waiter logic to load balance console writes") Link: http://lkml.kernel.org/r/[email protected] Cc: Steven Rostedt <[email protected]> Cc: [email protected] Cc: Tejun Heo <[email protected]> Suggested-by: Sergey Senozhatsky <[email protected]> Reviewed-by: Sergey Senozhatsky <[email protected]> Signed-off-by: Petr Mladek <[email protected]>
2018-02-27mmc: sdhci-pci: Fix S0i3 for Intel BYT-based controllersAdrian Hunter1-4/+31
Tuning can leave the IP in an active state (Buffer Read Enable bit set) which prevents the entry to low power states (i.e. S0i3). Data reset will clear it. Generally tuning is followed by a data transfer which will anyway sort out the state, so it is rare that S0i3 is actually prevented. Signed-off-by: Adrian Hunter <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]>
2018-02-27gpio: Handle deferred probing in of_find_gpio() properlyChen-Yu Tsai1-1/+1
of_get_named_gpiod_flags() used directly in of_find_gpio() or indirectly through of_find_spi_gpio() or of_find_regulator_gpio() can return -EPROBE_DEFER. This gets overwritten by the subsequent of_find_*_gpio() calls. This patch fixes this by trying of_find_spi_gpio() or of_find_regulator_gpio() only if deferred probing was not requested by the previous of_get_named_gpiod_flags() call. Fixes: 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO properties") Fixes: c85823390215 ("gpio: of: Support SPI nonstandard GPIO properties") Signed-off-by: Chen-Yu Tsai <[email protected]> [Augmented to fit with Maxime's patch] Signed-off-by: Linus Walleij <[email protected]>
2018-02-27gpiolib: Keep returning EPROBE_DEFER when we shouldMaxime Ripard1-0/+13
Commits c85823390215 ("gpio: of: Support SPI nonstandard GPIO properties") and 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO properties") have introduced a regression in the way error codes from of_get_named_gpiod_flags are handled. Previously, those errors codes were returned immediately, but the two commits mentioned above are now overwriting the error pointer, meaning that whatever value has been returned will be dropped in favor of whatever the two new functions will return. This might not be a big deal except for EPROBE_DEFER, on which GPIOlib customers will depend on, and that will now be returned as an hard error which means that they will not probe anymore, instead of gently deferring their probe. Since EPROBE_DEFER basically means that we have found a valid property but there was no GPIO controller registered to handle it, fix this issues by returning it as soon as we encounter it. Fixes: c85823390215 ("gpio: of: Support SPI nonstandard GPIO properties") Fixes: 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO properties") Signed-off-by: Maxime Ripard <[email protected]> [Fold in fix to the fix] Signed-off-by: Linus Walleij <[email protected]>
2018-02-27virtio-gpu: fix ioctl and expose the fixed status to userspace.Dave Airlie2-6/+12
This exposes to mesa that it can use the fixed ioctl for querying later cap sets, cap set 1 is forever frozen in time. Signed-off-by: Dave Airlie <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Gerd Hoffmann <[email protected]>
2018-02-26tpm: fix potential buffer overruns caused by bit glitches on the busJeremy Boone2-0/+8
Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. If a bit does flip it could cause an overrun if it's in one of the size parameters, so sanity check that we're not overrunning the provided buffer when doing a memcpy(). Signed-off-by: Jeremy Boone <[email protected]> Cc: [email protected] Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: James Morris <[email protected]>
2018-02-26tpm: st33zp24: fix potential buffer overruns caused by bit glitches on the busJeremy Boone1-2/+2
Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. In all the driver _recv() functions, we need to use a u32 to unmarshal the response size, otherwise a bit flip of the 31st bit would cause the expected variable to go negative, which would then try to read a huge amount of data. Also sanity check that the expected amount of data is large enough for the TPM header. Signed-off-by: Jeremy Boone <[email protected]> Cc: [email protected] Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: James Morris <[email protected]>
2018-02-26tpm_i2c_infineon: fix potential buffer overruns caused by bit glitches on ↵Jeremy Boone1-2/+3
the bus Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. In all the driver _recv() functions, we need to use a u32 to unmarshal the response size, otherwise a bit flip of the 31st bit would cause the expected variable to go negative, which would then try to read a huge amount of data. Also sanity check that the expected amount of data is large enough for the TPM header. Signed-off-by: Jeremy Boone <[email protected]> Cc: [email protected] Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: James Morris <[email protected]>
2018-02-26tpm_i2c_nuvoton: fix potential buffer overruns caused by bit glitches on the busJeremy Boone1-2/+6
Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. In all the driver _recv() functions, we need to use a u32 to unmarshal the response size, otherwise a bit flip of the 31st bit would cause the expected variable to go negative, which would then try to read a huge amount of data. Also sanity check that the expected amount of data is large enough for the TPM header. Signed-off-by: Jeremy Boone <[email protected]> Cc: [email protected] Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: James Morris <[email protected]>
2018-02-26tpm_tis: fix potential buffer overruns caused by bit glitches on the busJeremy Boone1-2/+3
Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. In all the driver _recv() functions, we need to use a u32 to unmarshal the response size, otherwise a bit flip of the 31st bit would cause the expected variable to go negative, which would then try to read a huge amount of data. Also sanity check that the expected amount of data is large enough for the TPM header. Signed-off-by: Jeremy Boone <[email protected]> Cc: [email protected] Signed-off-by: James Bottomley <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: James Morris <[email protected]>
2018-02-26selftests: vm: update .gitignore with new testShuah Khan1-0/+1
Update .gitignore with new test. Signed-off-by: Shuah Khan <[email protected]>
2018-02-26selftests: memory-hotplug: silence test command echoShuah Khan1-1/+1
Silence the following command being printed while running test. ./mem-on-off-test.sh -r 2 && echo "selftests: memory-hotplug [PASS]" || echo "selftests: memory-hotplug [FAIL]" Signed-off-by: Shuah Khan <[email protected]>
2018-02-26selftests/futex: Fix line continuation in MakefileDaniel Díaz1-3/+3
The Makefile lacks a couple of line continuation backslashes in an `if' clause, which produces an error when make versions prior to 4.x are used for building the tests. $ make make[1]: Entering directory `/[...]/linux/tools/testing/selftests/futex' /bin/sh: -c: line 5: syntax error: unexpected end of file make[1]: *** [all] Error 1 make[1]: Leaving directory `/[...]/linux/tools/testing/selftests/futex' make: *** [all] Error 2 Signed-off-by: Daniel Díaz <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2018-02-26cpufreq: scpi: Fix incorrect arm_big_little config dependencySudeep Holla1-3/+3
Commit 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency) removed the SCPI cpufreq dependency on arm_big_little cpufreq driver. However the Kconfig entry still depends on ARM_BIG_LITTLE_CPUFREQ which is clearly wrong. This patch removes that unnecessary Kconfig dependency. Fixes: 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency) Reported-by: Quentin Perret <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-26cpufreq: scpi: invoke frequency-invariance setter functionDietmar Eggemann1-4/+12
Commit 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency) changed the cpufreq driver on juno from arm_big_little to scpi. The scpi set_target function does not call the frequency-invariance setter function arch_set_freq_scale() like the arm_big_little set_target function does. As a result the task scheduler load and utilization signals are not frequency-invariant on this platform anymore. Fix this by adding a call to arch_set_freq_scale() into scpi_cpufreq_set_target(). Fixes: 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency) Signed-off-by: Dietmar Eggemann <[email protected]> Acked-by: Sudeep Holla <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-26Merge branch 'idr-2018-02-06' of git://git.infradead.org/users/willy/linux-daxLinus Torvalds6-8/+75
Pull idr fixes from Matthew Wilcox: "One test-suite build fix for you and one run-time regression fix. The regression fix includes new tests to make sure they don't pop back up." * 'idr-2018-02-06' of git://git.infradead.org/users/willy/linux-dax: idr: Fix handling of IDs above INT_MAX radix tree test suite: Fix build
2018-02-26PCI: Allow release of resources that were never assignedChristian König1-0/+4
It is entirely possible that the BIOS wasn't able to assign resources to a device. In this case don't crash in pci_release_resource() when we try to resize the resource. Fixes: 8bb705e3e79d ("PCI: Add pci_resize_resource() for resizing BARs") Signed-off-by: Christian König <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> CC: [email protected] # v4.15+
2018-02-26ARM: dts: Set D-Link DNS-313 SATA to muxmode 0Linus Walleij1-1/+1
This stops the driver from trying to probe the ATA slave interface. The vendor code enables the slave interface but the driver in the vendor tree does not make use of it. Setting it to muxmode 0 disables the slave interface: the hardware only has the master interface connected to the one harddrive slot anyways. Without this change booting takes excessive time, so it is very annoying to end users. Fixes: dd5c0561db75 ("ARM: dts: Add basic devicetree for D-Link DNS-313") Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2018-02-26ARM: omap2: set CONFIG_LIRC=y in defconfigArnd Bergmann1-1/+1
The CONFIG_LIRC symbol has changed from 'tristate' to 'bool, so we now get a warning for omap2plus_defconfig: arch/arm/configs/omap2plus_defconfig:322:warning: symbol value 'm' invalid for LIRC This changes the file to mark the symbol as built-in to get rid of the warning. Fixes: a60d64b15c20 ("media: lirc: lirc interface should not be a raw decoder") Signed-off-by: Arnd Bergmann <[email protected]>
2018-02-26dax: fix vma_is_fsdax() helperDan Williams1-1/+1
Gerd reports that ->i_mode may contain other bits besides S_IFCHR. Use S_ISCHR() instead. Otherwise, get_user_pages_longterm() may fail on device-dax instances when those are meant to be explicitly allowed. Fixes: 2bb6d2837083 ("mm: introduce get_user_pages_longterm") Cc: <[email protected]> Reported-by: Gerd Rausch <[email protected]> Acked-by: Jane Chu <[email protected]> Reported-by: Haozhong Zhang <[email protected]> Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Dan Williams <[email protected]>
2018-02-26dax: ->direct_access does not sleep anymoreBoaz Harrosh1-6/+0
In Patch: [7a862fb] brd: remove dax support Dan Williams has removed the only might_sleep implementation of ->direct_access. So we no longer need to check for it. CC: Dan Williams <[email protected]> Signed-off-by: Boaz Harrosh <[email protected]> Signed-off-by: Dan Williams <[email protected]>
2018-02-26idr: Fix handling of IDs above INT_MAXMatthew Wilcox2-6/+59
Khalid reported that the kernel selftests are currently failing: selftests: test_bpf.sh ======================================== test_bpf: [FAIL] not ok 1..8 selftests: test_bpf.sh [FAIL] He bisected it to 6ce711f2750031d12cec91384ac5cfa0a485b60a ("idr: Make 1-based IDRs more efficient"). The root cause is doing a signed comparison in idr_alloc_u32() instead of an unsigned comparison. I went looking for any similar problems and found a couple (which would each result in the failure to warn in two situations that aren't supposed to happen). I knocked up a few test-cases to prove that I was right and added them to the test-suite. Reported-by: Khalid Aziz <[email protected]> Tested-by: Khalid Aziz <[email protected]> Signed-off-by: Matthew Wilcox <[email protected]>
2018-02-26blktrace_api.h: fix comment for struct blk_user_trace_setupEric Biggers1-1/+1
'struct blk_user_trace_setup' is passed to BLKTRACESETUP, not BLKTRACESTART. Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.