- 13 May, 2015 40 commits
-
-
Alex Deucher authored
commit cd17e02f upstream. Seems to have problems with high mclks. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alex Deucher authored
commit 7fe04d6f upstream. Fixes display problems with some monitors when audio is not enabled. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89505 https://bugzilla.kernel.org/show_bug.cgi?id=94171 Plus several reports on IRC. Signed-off-by:
-
Michel Dänzer authored
commit b421ed15 upstream. The number of relocs is passed in by userspace and can be large. It has been observed to cause kcalloc failures in the wild. Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 38aef154 upstream. Selectively enable which packets we send based on monitor caps. Signed-off-by:
-
Alex Deucher authored
commit 0f55db36 upstream. Otherwise the driver may try and send audio which may confuse the monitor. v2: set pin to NULL if no audio v3: avoid crash with analog encoders Signed-off-by:
-
Alex Deucher authored
commit 362ff251 upstream. Don't enable the audio and avi infoframes and audio stream until all the state is set up. Signed-off-by:
-
Alex Deucher authored
commit 12428327 upstream. It's mostly duplicated with evergreen_dp_enable. This is a prerequisite for fix implemented in another patch. Signed-off-by:
-
Alex Deucher authored
commit 304f07e9 upstream. Set the line first, then enable the stream. May fix pink line problems on some displays. Signed-off-by:
-
Christoph Hellwig authored
commit 579d69bc upstream. The 3w-sas driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reported-by:
Torsten Luettgert <ml-lkml@enda.eu> Tested-by:
Bernd Kardatzki <Bernd.Kardatzki@med.uni-tuebingen.de> Acked-by:
Adam Radford <aradford@gmail.com> Signed-off-by:
James Bottomley <JBottomley@Odin.com> Signed-off-by:
-
Christoph Hellwig authored
commit 118c855b upstream. The 3w-9xxx driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by:
-
Christoph Hellwig authored
commit 9cd95546 upstream. The 3w-xxxx driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by:
-
Mike Christie authored
commit 35e9a9f9 upstream. This works around a issue with qnap iscsi targets not handling large IOs very well. The target returns: VPD INQUIRY: Block limits page (SBC) Maximum compare and write length: 1 blocks Optimal transfer length granularity: 1 blocks Maximum transfer length: 4294967295 blocks Optimal transfer length: 4294967295 blocks Maximum prefetch, xdread, xdwrite transfer length: 0 blocks Maximum unmap LBA count: 8388607 Maximum unmap block descriptor count: 1 Optimal unmap granularity: 16383 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0xffffffff blocks Maximum atomic transfer length: 0 Atomic alignment: 0 Atomic transfer length granularity: 0 and it is *sometimes* able to handle at least one IO of size up to 8 MB. We have seen in traces where it will sometimes work, but other times it looks like it fails and it looks like it returns failures if we send multiple large IOs sometimes. Also it looks like it can return 2 different errors. It will sometimes send iscsi reject errors indicating out of resources or it will send invalid cdb illegal requests check conditions. And then when it sends iscsi rejects it does not seem to handle retries when there are command sequence holes, so I could not just add code to try and gracefully handle that error code. The problem is that we do not have a good contact for the company, so we are not able to determine under what conditions it returns which error and why it sometimes works. So, this patch just adds a new black list flag to set targets like this to the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19 caused this regression, so I also ccing stable. Reported-by:
Christian Hesse <list@eworm.de> Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Reviewed-by:
-
Davide Italiano authored
commit 280227a7 upstream. fallocate() checks that the file is extent-based and returns EOPNOTSUPP in case is not. Other tasks can convert from and to indirect and extent so it's safe to check only after grabbing the inode mutex. Signed-off-by:
Davide Italiano <dccitaliano@gmail.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Lukas Czerner authored
commit d2dc317d upstream. Currently it is possible to lose whole file system block worth of data when we hit the specific interaction with unwritten and delayed extents in status extent tree. The problem is that when we insert delayed extent into extent status tree the only way to get rid of it is when we write out delayed buffer. However there is a limitation in the extent status tree implementation so that when inserting unwritten extent should there be even a single delayed block the whole unwritten extent would be marked as delayed. At this point, there is no way to get rid of the delayed extents, because there are no delayed buffers to write out. So when a we write into said unwritten extent we will convert it to written, but it still remains delayed. When we try to write into that block later ext4_da_map_blocks() will set the buffer new and delayed and map it to invalid block which causes the rest of the block to be zeroed loosing already written data. For now we can fix this by simply not allowing to set delayed status on written extent in the extent status tree. Also add WARN_ON() to make sure that we notice if this happens in the future. This problem can be easily reproduced by running the following xfs_io. xfs_io -f -c "pwrite -S 0xaa 4096 2048" \ -c "falloc 0 131072" \ -c "pwrite -S 0xbb 65536 2048" \ -c "fsync" /mnt/test/fff echo 3 > /proc/sys/vm/drop_caches xfs_io -c "pwrite -S 0xdd 67584 2048" /mnt/test/fff This can be theoretically also reproduced by at random by running fsx, but it's not very reliable, though on machines with bigger page size (like ppc) this can be seen more often (especially xfstest generic/127) Signed-off-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
-
Hans de Goede authored
commit 8e779c6c upstream. Testing has shown that ASM1053 devices do not work properly with transfers larger than 240 sectors, so set max_sectors to 240 on these. Reported-by:
Steve Bangert <sbangert@frontier.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Tested-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Hans de Goede authored
commit ee136af4 upstream. The usb-storage driver sets max_sectors = 240 in its scsi-host template, for uas we do not want to do that for all devices, but testing has shown that some devices need it. This commit adds a US_FL_MAX_SECTORS_240 flag for such devices, and implements support for it in uas.c, while at it it also adds support for US_FL_MAX_SECTORS_64 to uas.c. Signed-off-by:
-
Hans de Goede authored
commit a5011d44 upstream. uas_use_uas_driver may set some US_FL_foo flags during detection, currently these are stored in a local variable and then throw away, but these may be of interest to the caller, so add an extra parameter to (optionally) return the detected flags, and use this in the uas driver. Signed-off-by:
-
Ilya Dryomov authored
commit 082a75da upstream. When we end I/O struct request with error, we need to pass obj_request->length as @nr_bytes so that the entire obj_request worth of bytes is completed. Otherwise block layer ends up confused and we trip on rbd_assert(more ^ (which == img_request->obj_request_count)); in rbd_img_obj_callback() due to more being true no matter what. We already do it in most cases but we are missing some, in particular those where we don't even get a chance to submit any obj_requests, due to an early -ENOMEM for example. A number of obj_request->xferred assignments seem to be redundant but I haven't touched any of obj_request->xferred stuff to keep this small and isolated. Cc: Alex Elder <elder@linaro.org> Reported-by:
Shawn Edwards <lesser.evil@gmail.com> Reviewed-by:
Sage Weil <sage@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Ludovic Desroches authored
commit a8d4e016 upstream. Maxburst was not set when doing the dma slave configuration. This value is checked by the recently introduced xdmac. It causes an error when doing the slave configuration and so prevents from using dma. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Chris Bainbridge authored
commit 61f8ff69 upstream. Commit 9faf6136 (ACPI / SBS: Disable smart battery manager on Apple) introduced a regression disabling the SBS battery manager. The battery manager should be marked as present when acpi_manager_get_info() returns 0. Fixes: 9faf6136 (ACPI / SBS: Disable smart battery manager on Apple) Signed-off-by:
Chris Bainbridge <chris.bainbridge@gmail.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Omar Sandoval authored
commit 909e26dc upstream. Whenever the check for a send in progress introduced in commit 521e0546 (btrfs: protect snapshots from deleting during send) is hit, we return without unlocking inode->i_mutex. This is easy to see with lockdep enabled: [ +0.000059] ================================================ [ +0.000028] [ BUG: lock held when returning to user space! ] [ +0.000029] 4.0.0-rc5-00096-g3c435c1e #93 Not tainted [ +0.000026] ------------------------------------------------ [ +0.000029] btrfs/211 is leaving the kernel with locks still held! [ +0.000029] 1 lock held by btrfs/211: [ +0.000023] #0: (&type->i_mutex_dir_key){+.+.+.}, at: [<ffffffff8135b8df>] btrfs_ioctl_snap_destroy+0x2df/0x7a0 Make sure we unlock it in the error path. Reviewed-by:
Filipe Manana <fdmanana@suse.com> Reviewed-by:
David Sterba <dsterba@suse.cz> Signed-off-by:
Omar Sandoval <osandov@osandov.com> Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
Bard Liao authored
commit 60a8d62b upstream. DMIC clock source is not from codec system clock directly. it is generated from the division of system clock. And it should be 256 * sample rate of AIF1. Signed-off-by:
Bard Liao <bardliao@realtek.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Charles Keepax authored
commit a2d97723 upstream. Correct small copy and paste error where autodisable was not being enabled for the SOC_DAPM_SINGLE_TLV_AUTODISABLE control. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
-
Bard Liao authored
commit 74d6ea52 upstream. The PLL output will be unstable in some cases. We can fix it by setting some registers. Signed-off-by:
-
Wei Yongjun authored
commit 427ced4b upstream. In case of error, the function devm_kzalloc() returns NULL not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Acked-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
-
Wei Yongjun authored
commit c479163a upstream. In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by:
Krzysztof Kozlowski <k.kozlowski.k@gmail.com> Signed-off-by:
-
Li Jun authored
commit a5a356ce upstream. Wrongly release mutex lock during otg_statemachine may result in re-enter otg_statemachine, which is not allowed, we should do next state transtition after previous one completed. Fixes: 826cfe75 ("usb: chipidea: add OTG fsm operation functions implementation") Signed-off-by:
Li Jun <jun.li@freescale.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Dean Nelson authored
commit 2cff98b9 upstream. __dma_alloc() does a PAGE_ALIGN() on the passed in size argument before doing anything else. __dma_free() does not. And because it doesn't, it is possible to leak memory should size not be an integer multiple of PAGE_SIZE. The solution is to add a PAGE_ALIGN() to __dma_free() like is done in __dma_alloc(). Additionally, this patch removes a redundant PAGE_ALIGN() from __dma_alloc_coherent(), since __dma_alloc_coherent() can only be called from __dma_alloc(), which already does a PAGE_ALIGN() before the call. Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Dean Nelson <dnelson@redhat.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Marek Szyprowski authored
commit 6829e274 upstream. Buffers allocated by dma_alloc_coherent() are always zeroed on Alpha, ARM (32bit), MIPS, PowerPC, x86/x86_64 and probably other architectures. It turned out that some drivers rely on this 'feature'. Allocated buffer might be also exposed to userspace with dma_mmap() call, so clearing it is desired from security point of view to avoid exposing random memory to userspace. This patch unifies dma_alloc_coherent() behavior on ARM64 architecture with other implementations by unconditionally zeroing allocated buffer. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Michal Simek authored
commit 5c90c07b upstream. For systems with CONFIG_SERIAL_OF_PLATFORM=y and device_type = "serial"; property in DT of_serial.c driver maps and unmaps IRQ (because driver probe fails). Then a driver is called but irq mapping is not created that's why driver is failing again in again on request_irq(). Based on this use platform_get_irq() instead of platform_get_resource() which is doing irq_desc allocation and driver itself can request IRQ. Fix both xilinx serial drivers in the tree. Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Michal Simek authored
commit 6befa9d8 upstream. Do not probe all serial drivers by of_serial.c which are using device_type = "serial"; property. Only drivers which have valid compatible strings listed in the driver should be probed. When PORT_UNKNOWN is setup probe will fail anyway. Arnd quotation about driver historical background: "when I wrote that driver initially, the idea was that it would get used as a stub to hook up all other serial drivers but after that, the common code learned to create platform devices from DT" This patch fix the problem with on the system with xilinx_uartps and 16550a where of_serial failed to register for xilinx_uartps and because of irq_dispose_mapping() removed irq_desc. Then when xilinx_uartps was asking for irq with request_irq() EINVAL is returned. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Quentin Casasnovas authored
commit 0d3bba02 upstream. Phil and I found out a problem with commit: 7e860a6e ("cdc-acm: add sanity checks") It added some sanity checks to ignore potential garbage in CDC headers but also introduced a potential infinite loop. This can happen at the first loop iteration (elength = 0 in that case) if the description isn't a DT_CS_INTERFACE or later if 'buffer[0]' is zero. It should also be noted that the wrong length was being added to 'buffer' in case 'buffer[1]' was not a DT_CS_INTERFACE descriptor, since elength was assigned after that check in the loop. A specially crafted USB device could be used to trigger this infinite loop. Fixes: 7e860a6e ("cdc-acm: add sanity checks") Signed-off-by:
Phil Turnbull <phil.turnbull@oracle.com> Signed-off-by:
Quentin Casasnovas <quentin.casasnovas@oracle.com> CC: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> CC: Oliver Neukum <oneukum@suse.de> CC: Adam Lee <adam8157@gmail.com> Signed-off-by:
-
Takashi Iwai authored
commit 7290006d upstream. This patch adds the missing flag to enable "Mute-LED Mode" mixer enum ctl for Thinkpads that have also the software mute-LED control. Reported-and-tested-by:
Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit ee52e56e upstream. The mute-LED mode control has the fixed on/off states that are supposed to remain on/off regardless of the master switch. However, this doesn't work actually because the vmaster hook is called in the vmaster code itself. This patch fixes it by calling the hook indirectly after checking the mute LED mode. Reported-and-tested-by:
-
Peter Zubaj authored
commit 7241ea55 upstream. Looks like audigy emu10k2 (probably emu10k1 - sb live too) support two modes for DMA. Second mode is useful for 64 bit os with more then 2 GB of ram (fixes problems with big soundfont loading) 1) 32MB from 2 GB address space using 8192 pages (used now as default) 2) 16MB from 4 GB address space using 4096 pages Mode is set using HCFG_EXPANDED_MEM flag in HCFG register. Also format of emu10k2 page table is then different. Signed-off-by:
Peter Zubaj <pzubaj@marticonet.sk> Tested-by:
-
Takashi Iwai authored
commit d0226082 upstream. Some models provide too long string for the shortname that has 32bytes including the terminator, and it results in a non-terminated string exposed to the user-space. This isn't too critical, though, as the string is stopped at the succeeding longname string. This patch fixes such entries by dropping "SB" prefix (it's enough to fit within 32 bytes, so far). Meanwhile, it also changes strcpy() with strlcpy() to make sure that this kind of problem won't happen in future, too. Signed-off-by:
-
Takashi Iwai authored
commit 1c94e65c upstream. The OSS emulation in synth-emux helper has a potential AB/BA deadlock at the simultaneous closing and opening: close -> snd_seq_release() -> sne_seq_free_client() -> snd_seq_delete_all_ports(): takes client->ports_mutex -> port_delete() -> snd_emux_unuse(): takes emux->register_mutex open -> snd_seq_oss_open() -> snd_emux_open_seq_oss(): takes emux->register_mutex -> snd_seq_event_port_attach() -> snd_seq_create_port(): takes client->ports_mutex This patch addresses the deadlock by reducing the rance taking emux->register_mutex in snd_emux_open_seq_oss(). The lock is needed for the refcount handling, so move it locally. The calls in emux_seq.c are already with the mutex, thus they are replaced with the version without mutex lock/unlock. Signed-off-by:
-
Takashi Iwai authored
commit 07b0e5d4 upstream. The emux-synth driver has a possible AB/BA mutex deadlock at unloading the emu10k1 driver: snd_emux_free() -> snd_emux_detach_seq(): mutex_lock(&emu->register_mutex) -> snd_seq_delete_kernel_client() -> snd_seq_free_client(): mutex_lock(®ister_mutex) snd_seq_release() -> snd_seq_free_client(): mutex_lock(®ister_mutex) -> snd_seq_delete_all_ports() -> snd_emux_unuse(): mutex_lock(&emu->register_mutex) Basically snd_emux_detach_seq() doesn't need a protection of emu->register_mutex as it's already being unregistered. So, we can get rid of this for avoiding the deadlock. Signed-off-by:
-
Markos Chandras authored
Commit 5306a545 upstream. Commit 32098ec7 ("MIPS: Makefile: Move the ASEs checks after setting the core's CFLAGS") re-arranged the MIPS ASE detection code and also added the current cflags to the detection logic. However, this introduced a few bugs. First of all, the mips-cflags should not be quoted since that ends up being passed as a string to subsequent commands leading to broken detection from the cc-option-* tools. Moreover, in order to avoid duplicating the cflags-y because of how cc-option works, we rework the logic so we pass only those cflags which are needed by the selected ASE. Finally, fix some typos resulting in MSA not being detected correctly. Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Fixes: Commit 32098ec7 ("MIPS: Makefile: Move the ASEs checks after setting the core's CFLAGS") Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9661/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Markos Chandras authored
Commit 48f8eaee upstream. Set good default FPU flags (FR0) for O32 binaries similar to what the kernel does for the N64/N32 ones. This also fixes a regression introduced in commit 46490b57 ("MIPS: kernel: elf: Improve the overall ABI and FPU mode checks") when MIPS_O32_FP64_SUPPORT is disabled. In that case, the mips_set_personality_fp() did not set the FPU mode at all because it assumed that the FPU mode was already set properly. That led to O32 userland problems. Signed-off-by:
Mans Rullgard <mans@mansr.com> Fixes: 46490b57 ("MIPS: kernel: elf: Improve the overall ABI and FPU mode checks") Tested-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Matthew Fortune <Matthew.Fortune@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/9344/Signed-off-by:
-
