Merge tag 'fixes-for-v4.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v4.6-rc3
We have two more fixes to f_midi. It should now
behave much better.
dwc3-keystone.c has gotten a fix which now allows it
to work on keystone device when running in
peripheral mode. A similar fix for DMA configuration
was made for udc-core, too.
We have a new PCI ID for Intel's Broxton
platform. DWC3 can run on those platforms as well.
And we also have some dwc2 got a fix for dr_mode
usage, while renesas controller got 3 important
fixes: a NULL pointer deref fix, IRQ <-> DMA race
fix, and a fix to prevent a situation where we would
queue a request to a disabled endpoint.
Dan Carpenter [Wed, 6 Apr 2016 18:38:56 +0000 (21:38 +0300)]
iommu/vt-d: Silence an uninitialized variable warning
My static checker complains that "dma_alias" is uninitialized unless we
are dealing with a pci device. This is true but harmless. Anyway, we
can flip the condition around to silence the warning.
John Keeping [Tue, 5 Apr 2016 14:05:46 +0000 (15:05 +0100)]
iommu/rockchip: Fix "is stall active" check
Since commit cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi
slaves") rk_iommu_is_stall_active() always returns false because the
bitwise AND operates on the boolean flag promoted to an integer and a
value that is either zero or BIT(2).
Explicitly convert the right-hand value to a boolean so that both sides
are guaranteed to be either zero or one.
rk_iommu_is_paging_enabled() does not suffer from the same problem since
RK_MMU_STATUS_PAGING_ENABLED is BIT(0), but let's apply the same change
for consistency and to make it clear that it's correct without needing
to lookup the value.
iommu: Don't overwrite domain pointer when there is no default_domain
IOMMU drivers that do not support default domains, but make
use of the the group->domain pointer can get that pointer
overwritten with NULL on device add/remove.
Make sure this can't happen by only overwriting the domain
pointer when it is NULL.
Stefan Hajnoczi [Tue, 29 Mar 2016 15:43:45 +0000 (16:43 +0100)]
virtio: add VIRTIO_CONFIG_S_NEEDS_RESET device status bit
The VIRTIO 1.0 specification added the DEVICE_NEEDS_RESET device status
bit in "VIRTIO-98: Add DEVICE_NEEDS_RESET". This patch defines the
device status bit in the uapi header file so that both the kernel and
userspace applications can use it.
The bit is currently unused by the virtio guest drivers and vhost.
According to the spec "a good implementation will try to recover by
issuing a reset". This is not attempted here because it requires
auditing the virtio drivers to ensure there are no resource leaks or
crashes if the device needs to be reset mid-operation.
See "2.1 Device Status Field" in the VIRTIO 1.0 specification for
details.
Gabriel merged support for QEMU FW CFG interface, but there's apparently
no official maintainer. It's also possible that this will grow more
interfaces in future. I'll happily co-maintain it and handle pull
requests together with the rest of the PV stuff I maintain.
Gabriel Somlo [Tue, 8 Mar 2016 18:30:50 +0000 (13:30 -0500)]
firmware: qemu_fw_cfg.c: hold ACPI global lock during device access
Allowing for the future possibility of implementing AML-based
(i.e., firmware-triggered) access to the QEMU fw_cfg device,
acquire the global ACPI lock when accessing the device on behalf
of the guest-side sysfs driver, to prevent any potential race
conditions.
Alexey Brodkin [Thu, 3 Mar 2016 17:01:48 +0000 (20:01 +0300)]
ARC: [plat-axs103] Enable loop block devices
As mentioned in LTP's README.ARC:
------------->8------------
Requirements for the environment
* Linux must be built with support of loop block devices. Thus it's
necessary to enable these Linux kernel options:
CONFIG_BLK_DEV
CONFIG_BLK_DEV_LOOP
------------->8------------
enabling loop block devices.
That among other things lead to additional 10 fatal signals
appearing during LTP run.
Alexey Brodkin [Mon, 28 Mar 2016 11:36:38 +0000 (14:36 +0300)]
arc: Add our own implementation of fb_pgprotect()
During mmaping of frame-buffer pages to user-space
fb_protect() is called to set proper page settings.
In case of ARC we need to mark pages that are mmaped to
user as uncached because of 2 reasons:
* Huge amount of data if passing through data cache will
thrash cache a lot making cache almost useless for other
less traffic hungry processes.
* Data written by user in FB will be immediately available for
hardware (such as PGU etc) without requirements to flush data
cache regularly.
Commit 5f8fc43217a0 ("PCI: Include pci/pcie/Kconfig directly from
pci/Kconfig") in linux-next changed drivers/pci/Kconfig to include
drivers/pci/pcie/Kconfig itself, so that architectures do not need
to source both files themselves. ARC just recently gained PCI support
through commit 6b3fb77998dd ("ARC: Add PCI support"), but this change
was based on the old behaviour of the Kconfig files. This makes
Kconfig now spit out the following warnings:
drivers/pci/pcie/Kconfig:61:warning: choice value used outside its choice group
drivers/pci/pcie/Kconfig:67:warning: choice value used outside its choice group
drivers/pci/pcie/Kconfig:74:warning: choice value used outside its choice group
This change updates the Kconfig file for ARC, dropping the now
unnecessary 'source' statement, which makes the warning disappear.
Josh Boyer [Thu, 10 Mar 2016 14:48:52 +0000 (09:48 -0500)]
USB: serial: ftdi_sio: Add support for ICP DAS I-756xU devices
A Fedora user reports that the ftdi_sio driver works properly for the
ICP DAS I-7561U device. Further, the user manual for these devices
instructs users to load the driver and add the ids using the sysfs
interface.
Add support for these in the driver directly so that the devices work
out of the box instead of needing manual configuration.
... which macros are (ab-)using the fact that __VA_ARGS__ can be used
to shift parameter positions in macro arguments without breaking the
build and so can be used to call separate C functions depending on
the number of arguments of the macro.
This allowed easy migration of these 3 GUP APIs, as both these variants
worked at the C level:
new:
ret = get_user_pages(address, 1, 1, 0, &page, NULL);
... while we also generated a (functionally harmless but noticeable) build
time warning if the old API was used. As there are over 300 uses of these
APIs, this trick eased the migration of the API and avoided excessive
migration pain in linux-next.
Now, with its work done, get rid of all of that complication and ugliness:
... where the linecount of the migration hack was further inflated by the
fact that there are NOMMU variants of these GUP APIs as well.
Much of the conversion was done in linux-next over the past couple of months,
and Linus recently removed all remaining old API uses from the upstream tree
in the following upstrea commit:
cb107161df3c ("Convert straggling drivers to new six-argument get_user_pages()")
There was one more old-API usage in mm/gup.c, in the CONFIG_HAVE_GENERIC_RCU_GUP
code path that ARM, ARM64 and PowerPC uses.
After this commit any old API usage will break the build.
[ Also fixed a PowerPC/HAVE_GENERIC_RCU_GUP warning reported by Stephen Rothwell. ]
Bjørn Mork [Wed, 30 Mar 2016 09:08:33 +0000 (11:08 +0200)]
drm/i915: fix deadlock on lid open
commit e2c8b8701e2d moved modeset locking inside resume/suspend
functions, but missed a code path only executed on lid close/open
on older hardware. The result was a deadlock when closing and
opening the lid without suspending on such hardware:
=============================================
[ INFO: possible recursive locking detected ]
4.6.0-rc1 #385 Not tainted
---------------------------------------------
kworker/0:3/88 is trying to acquire lock:
(&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915]
but task is already holding lock:
(&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm]
other info that might help us debug this:
Possible unsafe locking scenario:
Filipe Manana [Wed, 30 Mar 2016 22:37:21 +0000 (23:37 +0100)]
Btrfs: fix file/data loss caused by fsync after rename and new inode
If we rename an inode A (be it a file or a directory), create a new
inode B with the old name of inode A and under the same parent directory,
fsync inode B and then power fail, at log tree replay time we end up
removing inode A completely. If inode A is a directory then all its files
are gone too.
Example scenarios where this happens:
This is reproducible with the following steps, taken from a couple of
test cases written for fstests which are going to be submitted upstream
soon:
The next time the fs is mounted, log tree replay happens and
the directory "y" does not exist nor do the files "foo" and
"bar" exist anywhere (neither in "y" nor in "x", nor the root
nor anywhere).
The next time the fs is mounted, log tree replay happens and the
file "bar" does not exists anymore. A file with the name "foo"
exists and it matches the second file we created.
Another related problem that does not involve file/data loss is when a
new inode is created with the name of a deleted snapshot and we fsync it:
The next time the fs is mounted the log replay procedure fails because
it attempts to delete the snapshot entry (which has dir item key type
of BTRFS_ROOT_ITEM_KEY) as if it were a regular (non-root) entry,
resulting in the following error that causes mount to fail:
Fix this by forcing a transaction commit when such cases happen.
This means we check in the commit root of the subvolume tree if there
was any other inode with the same reference when the inode we are
fsync'ing is a new inode (created in the current transaction).
Test cases for fstests, covering all the scenarios given above, were
submitted upstream for fstests:
* fstests: generic test for fsync after renaming directory
https://patchwork.kernel.org/patch/8694281/
* fstests: generic test for fsync after renaming file
https://patchwork.kernel.org/patch/8694301/
* fstests: add btrfs test for fsync after snapshot deletion
https://patchwork.kernel.org/patch/8670671/
mailbox: pcc: Don't access an unmapped memory address space
The acpi_pcc_probe() may end up accessing memory outside of the PCCT
table space causing the kernel panic(). Increment the pcct_entry
pointer after parsing 'HW-reduced Communications Subspace' to fix
the problem. This change also enables the parsing of subtable at
index 0.
Dave Airlie [Wed, 6 Apr 2016 21:08:46 +0000 (07:08 +1000)]
Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
Lots of misc bug fixes for radeon and amdgpu and one for ttm.
- fix vram info fetching on Fiji and unposted boards
- additional vblank fixes from the conversion to drm_vblank_on/off
- UVD dGPU suspend and resume fixes
- lots of powerplay fixes
- fix a fence leak in the pageflip code
- ttm fix for platforms where CPU is 32 bit, but physical addresses are >32bits
* 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux: (21 commits)
drm/amdgpu: total vram size also reduces pin size
drm/amd/powerplay: add uvd/vce dpm enabling flag default.
drm/amd/powerplay: fix issue that resume back, dpm can't work on FIJI.
drm/amdgpu: save and restore the firwmware cache part when suspend resume
drm/amdgpu: save and restore UVD context with suspend and resume
drm/ttm: use phys_addr_t for ttm_bus_placement
drm/radeon: Only call drm_vblank_on/off between drm_vblank_init/cleanup
drm/amdgpu: fence wait old rcu slot
drm/amdgpu: fix leaking fence in the pageflip code
drm/amdgpu: print vram type rather than just DDR
drm/amdgpu/gmc: use proper register for vram type on Fiji
drm/amdgpu/gmc: move vram type fetching into sw_init
drm/amdgpu: Set vblank_disable_allowed = true
drm/radeon: Set vblank_disable_allowed = true
drm/amd/powerplay: Need to change boot to performance state in resume.
drm/amd/powerplay: add new Fiji function for not setting same ps.
drm/amdgpu: check dpm state before pm system fs initialized.
drm/amd/powerplay: notify amdgpu whether dpm is enabled or not.
drm/amdgpu: Not support disable dpm in powerplay.
drm/amdgpu: add an cgs interface to notify amdgpu the dpm state.
...
> Your mail to 'Intel-wired-lan' with the subject
>
> [PATCH net-next] net: intel: remove dead links
>
> Is being held until the list moderator can review it for approval.
>
> The reason it is being held:
>
> Post by non-member to a members-only list
Some of these tests proved useful with the powerpc eBPF JIT port due to
sign-extended 16-bit immediate loads. Though some of these aspects get
covered in other tests, it is better to have explicit tests so as to
quickly tag the precise problem.
x86: remove the kernel code/data/bss resources from /proc/iomem
Let's see if anybody even notices. I doubt anybody uses this, and it
does expose addresses that should be randomized, so let's just remove
the code. It's old and traditional, and it used to be cute, but we
should have removed this long ago.
If it turns out anybody notices and this breaks something, we'll have to
revert this, and maybe we'll end up using other approaches instead
(using %pK or similar). But removing unnecessary code is always the
preferred option.
stmmac: fix adjust link call in case of a switch is attached
While initializing the phy, the stmmac driver sets the
PHY_IGNORE_INTERRUPT so the PAL won't call the adjust hook
that is needed, on some platforms, e.g. STi, to invoke the glue.
The patch allows the PAL to poll the stmmac_adjust_link just one time
in case of a switch is attached, setting later the PHY_IGNORE_INTERRUPT
flag.
Moving this kind of logic inside the adjust_link it makes sense to
anticipate the check for EEE that will never initialized in this
scenario.
samples/bpf: Fix build breakage with map_perf_test_user.c
Building BPF samples is failing with the below error:
samples/bpf/map_perf_test_user.c: In function ‘main’:
samples/bpf/map_perf_test_user.c:134:9: error: variable ‘r’ has
initializer but incomplete type
struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
^
samples/bpf/map_perf_test_user.c:134:21: error: ‘RLIM_INFINITY’
undeclared (first use in this function)
struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
^
samples/bpf/map_perf_test_user.c:134:21: note: each undeclared
identifier is reported only once for each function it appears in
samples/bpf/map_perf_test_user.c:134:9: warning: excess elements in
struct initializer [enabled by default]
struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
^
samples/bpf/map_perf_test_user.c:134:9: warning: (near initialization
for ‘r’) [enabled by default]
samples/bpf/map_perf_test_user.c:134:9: warning: excess elements in
struct initializer [enabled by default]
samples/bpf/map_perf_test_user.c:134:9: warning: (near initialization
for ‘r’) [enabled by default]
samples/bpf/map_perf_test_user.c:134:16: error: storage size of ‘r’
isn’t known
struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
^
samples/bpf/map_perf_test_user.c:139:2: warning: implicit declaration of
function ‘setrlimit’ [-Wimplicit-function-declaration]
setrlimit(RLIMIT_MEMLOCK, &r);
^
samples/bpf/map_perf_test_user.c:139:12: error: ‘RLIMIT_MEMLOCK’
undeclared (first use in this function)
setrlimit(RLIMIT_MEMLOCK, &r);
^
samples/bpf/map_perf_test_user.c:134:16: warning: unused variable ‘r’
[-Wunused-variable]
struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
^
make[2]: *** [samples/bpf/map_perf_test_user.o] Error 1
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
Pull rdma fixes from Doug Ledford:
"I'm back from PTO. These issues cropped up while I was gone and are
simple fixes. I'll have more after I've caught up, but I wanted to
get these in quick.
Two minor fixes for 4.6-rc2:
- Fix mlx5 build error when on demand paging is not enabled
- Fix possible uninit variable in new i40iw driver"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
i40iw: avoid potential uninitialized variable use
IB/mlx5: fix VFs callback function prototypes
Arnd Bergmann [Wed, 23 Mar 2016 10:34:36 +0000 (11:34 +0100)]
i40iw: avoid potential uninitialized variable use
gcc finds that the i40iw_make_cm_node() function in the recently added
i40iw driver uses an uninitilized variable as an index into an array
if CONFIG_IPV6 is disabled and the driver uses IPv6 mode:
drivers/infiniband/hw/i40iw/i40iw_cm.c: In function 'i40iw_make_cm_node':
drivers/infiniband/hw/i40iw/i40iw_cm.c:2206:52: error: 'arpindex' may be used uninitialized in this function [-Werror=maybe-uninitialized]
ether_addr_copy(cm_node->rem_mac, iwdev->arp_table[arpindex].mac_addr);
As far as I can tell, this code path can not be used because the ipv4
variable is always set with CONFIG_IPV6 is disabled, but it's better
to be sure and prevent the undefined behavior, as well as shut up
that warning in a proper way.
This adds an 'else' clause for the case we get the warning about,
causing the function to return an error in a controlled way.
To avoid adding extra mess with combined io()/#ifdef clauses,
I'm also converting the existing #ifdef into a more readable
if(IS_ENABLED()) check.
Arnd Bergmann [Wed, 23 Mar 2016 10:37:45 +0000 (11:37 +0100)]
IB/mlx5: fix VFs callback function prototypes
The previous patch that added a couple of callback functions put
the declarations inside of an #ifdef CONFIG_INFINIBAND_ON_DEMAND_PAGING,
which causes the build to fail if that option is disabled:
drivers/infiniband/hw/mlx5/main.c: In function 'mlx5_ib_add':
drivers/infiniband/hw/mlx5/main.c:2358:31: error: 'mlx5_ib_get_vf_config' undeclared (first use in this function)
This moves the four declarations below the #ifdef section so they
are always available.
John Ogness [Wed, 6 Apr 2016 10:01:47 +0000 (13:01 +0300)]
dmaengine: edma: special case slot limit workaround
Currently drivers are limited to 19 slots for cyclic transfers.
However, if the DMA burst size is the same as the period size,
the period size can be changed to the full buffer size and
intermediate interrupts activated. Since intermediate interrupts
will trigger for each burst and the burst size is the same as
the period size, the driver will get interrupts each period as
expected. This has the benefit of allowing the functionality of
many more slots, but only uses 2 slots.
This workaround is only active if more than 19 slots are needed
and the burst size matches the period size.
Peter Ujfalusi [Wed, 6 Apr 2016 10:01:46 +0000 (13:01 +0300)]
dmaengine: edma: Remove dynamic TPTC power management feature
The dynamic or on demand pm_runtime does not work correctly on am335x and
am437x due to interference with hwmod.
Fall back using the pm_runtime usage as it was in the old driver stack,
meaning that at probe time call pm_runtime_enable() and
pm_runtime_get_sync() for the TPTCs as well.
Fixes: 1be5336bc7ba ("dmaengine: edma: New device tree binding") Signed-off-by: Peter Ujfalusi <[email protected]> Reported-by: Tero Kristo <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
The Keystone 2 supports DT-boot only, as result dma_mask will be
always configured properly from DT -
of_platform_device_create_pdata()->of_dma_configure(). More over,
dwc3-keystone.c can be built as module and in this case it's unsafe to
assign local variable as dma_mask.
Since commit 7ace8fc8219e ("usb: gadget: udc: core: Fix argument of
dma_map_single for IOMMU") it is not necessary to configure DMA for
usb_gadget device manually, because all DMA operation are performed
using parent/controller device.
assoc_array: don't call compare_object() on a node
Changes since V1: fixed the description and added KASan warning.
In assoc_array_insert_into_terminal_node(), we call the
compare_object() method on all non-empty slots, even when they're
not leaves, passing a pointer to an unexpected structure to
compare_object(). Currently it causes an out-of-bound read access
in keyring_compare_object detected by KASan (see below). The issue
is easily reproduced with keyutils testsuite.
Only call compare_object() when the slot is a leave.
KASan warning:
==================================================================
BUG: KASAN: slab-out-of-bounds in keyring_compare_object+0x213/0x240 at addr ffff880060a6f838
Read of size 8 by task keyctl/1655
=============================================================================
BUG kmalloc-192 (Not tainted): kasan: bad access detected
-----------------------------------------------------------------------------
arm64: KVM: unregister notifiers in hyp mode teardown path
Commit 1e947bad0b63 ("arm64: KVM: Skip HYP setup when already running
in HYP") re-organized the hyp init code and ended up leaving the CPU
hotplug and PM notifier even if hyp mode initialization fails.
Since KVM is not yet supported with ACPI, the above mentioned commit
breaks CPU hotplug in ACPI boot.
This patch fixes teardown_hyp_mode to properly unregister both CPU
hotplug and PM notifiers in the teardown path.
Marc Zyngier [Tue, 5 Apr 2016 15:11:47 +0000 (16:11 +0100)]
arm64: KVM: Warn when PARange is less than 40 bits
We always thought that 40bits of PA range would be the minimum people
would actually build. Anything less is terrifyingly small.
Turns out that we were both right and wrong. Nobody has ever built
such a system, but the ARM Foundation Model has a PARange set to 36bits.
Just because we can. Oh well. Now, the KVM API explicitely says that
we offer a 40bit PA space to the VM, so we shouldn't run KVM on
the Foundation Model at all.
That being said, this patch offers a less agressive alternative, and
loudly warns about the configuration being unsupported. You'll still
be able to run VMs (at your own risks, though).
This is just a workaround until we have a proper userspace API where
we report the PARange to userspace.
Marc Zyngier [Wed, 6 Apr 2016 08:37:22 +0000 (09:37 +0100)]
KVM: arm/arm64: Handle forward time correction gracefully
On a host that runs NTP, corrections can have a direct impact on
the background timer that we program on the behalf of a vcpu.
In particular, NTP performing a forward correction will result in
a timer expiring sooner than expected from a guest point of view.
Not a big deal, we kick the vcpu anyway.
But on wake-up, the vcpu thread is going to perform a check to
find out whether or not it should block. And at that point, the
timer check is going to say "timer has not expired yet, go back
to sleep". This results in the timer event being lost forever.
There are multiple ways to handle this. One would be record that
the timer has expired and let kvm_cpu_has_pending_timer return
true in that case, but that would be fairly invasive. Another is
to check for the "short sleep" condition in the hrtimer callback,
and restart the timer for the remaining time when the condition
is detected.
This patch implements the latter, with a bit of refactoring in
order to avoid too much code duplication.
Merge tag 'extcon-fixes-for-4.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-linus
Chanwoo writes:
Update extcon for v4.6-rc3
This patch fixes the following one issue:
- In extcon-palmas.c, the external abort happen when wake-up from suspend state
on BeagleBoard-X15 platform. So, drop the IRQF_EARLY_RESUME flag.
Dennis Kadioglu [Wed, 6 Apr 2016 06:39:01 +0000 (08:39 +0200)]
ALSA: usb-audio: Add a quirk for Plantronics BT300
Plantronics BT300 does not support reading the sample rate which leads
to many lines of "cannot get freq at ep 0x1". This patch adds the USB
ID of the BT300 to quirks.c and avoids those error messages.
Dave Airlie [Tue, 5 Apr 2016 23:48:53 +0000 (09:48 +1000)]
Merge tag 'imx-drm-next-2016-04-01' of git://git.pengutronix.de/git/pza/linux into drm-fixes
imx-drm: stricter plane parameter checking, dw_hdmi-imx and dmfc fixes
- Check whether plane parameters comply with IPU IDMAC limitations and
fix planar YUV 4:2:0 U/V offsets and stride
- Cleanup encoder in dw_hdmi-imx bind error path and
remove a superfluous platform_set_drvdata in dw_hdmi-imx
- DMFC setup fixes: lock the ipu_dmfc_init_channel function against
concurrent use, rename it to ipu_dmfc_config_wait4eot, and call
it after the FIFO size has been determined.
* tag 'imx-drm-next-2016-04-01' of git://git.pengutronix.de/git/pza/linux:
drm/imx: Don't set a gamma table size
drm/imx: ipuv3-plane: Configure DMFC wait4eot bit after slots are determined
gpu: ipu-v3: ipu-dmfc: Rename ipu_dmfc_init_channel to ipu_dmfc_config_wait4eot
gpu: ipu-v3: ipu-dmfc: Make function ipu_dmfc_init_channel() return void
gpu: ipu-v3: ipu-dmfc: Protect function ipu_dmfc_init_channel() with mutex
drm/imx: dw_hdmi: Don't call platform_set_drvdata()
drm/imx: dw_hdmi: Call drm_encoder_cleanup() in error path
drm/imx: ipuv3-plane: fix planar YUV 4:2:0 support
drm/imx: ipuv3-plane: Add more thorough checks for plane parameter limitations
gpu: ipu-cpmem: modify ipu_cpmem_set_yuv_planar_full for better control
ip6_tunnel: set rtnl_link_ops before calling register_netdevice
When creating an ip6tnl tunnel with ip tunnel, rtnl_link_ops is not set
before ip6_tnl_create2 is called. When register_netdevice is called, there
is no linkinfo attribute in the NEWLINK message because of that.
Setting rtnl_link_ops before calling register_netdevice fixes that.
Fixes: 0b112457229d ("ip6tnl: add support of link creation via rtnl") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Acked-by: Nicolas Dichtel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Paolo Bonzini:
"Miscellaneous bugfixes.
The ARM and s390 fixes are for new regressions from the merge window,
others are usual stable material"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
compiler-gcc: disable -ftracer for __noclone functions
kvm: x86: make lapic hrtimer pinned
s390/mm/kvm: fix mis-merge in gmap handling
kvm: set page dirty only if page has been writable
KVM: x86: reduce default value of halt_poll_ns parameter
KVM: Hyper-V: do not do hypercall userspace exits if SynIC is disabled
KVM: x86: Inject pending interrupt even if pending nmi exist
arm64: KVM: Register CPU notifiers when the kernel runs at HYP
arm64: kvm: 4.6-rc1: Fix VTCR_EL2 VS setting
Alexander Duyck [Wed, 2 Mar 2016 21:16:08 +0000 (16:16 -0500)]
e1000: Double Tx descriptors needed check for 82544
The 82544 has code that adds one additional descriptor per data buffer.
However we weren't taking that into account when determining the descriptors
needed for the next transmit at the end of the xmit_frame path.
This change takes that into account by doubling the number of descriptors
needed for the 82544 so that we can avoid a potential issue where we could
hang the Tx ring by loading frames with xmit_more enabled and then stopping
the ring without writing the tail.
In addition it adds a few more descriptors to account for some additional
workarounds that have been added over time.
Alexander Duyck [Wed, 2 Mar 2016 21:16:01 +0000 (16:16 -0500)]
e1000: Do not overestimate descriptor counts in Tx pre-check
The current code path is capable of grossly overestimating the number of
descriptors needed to transmit a new frame. This specifically occurs if
the skb contains a number of 4K pages. The issue is that the logic for
determining the descriptors needed is ((S) >> (X)) + 1. When X is 12 it
means that we were indicating that we required 2 descriptors for each 4K
page when we only needed one.
This change corrects this by instead adding (1 << (X)) - 1 to the S value
instead of adding 1 after the fact. This way we get an accurate descriptor
needed count as we are essentially doing a DIV_ROUNDUP().
Jesse Brandeburg [Mon, 29 Feb 2016 19:00:24 +0000 (11:00 -0800)]
i40e: fix errant PCIe bandwidth message
There was an error introduced with commit 3fced535079a ("i40e: X722 is
on the IOSF bus and does not report the PCI bus info"), where code was
added but the enabling flag is never set.
Merge tag 'spi-fix-v4.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A couple of driver specific fixes here that came in since the merge
window plus one core fix for locking in cases where a client driver
grabs a lock on the whole bus for an extended series of operations
that was introduced by the changes to support accelerated flash
operations"
* tag 'spi-fix-v4.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: rockchip: fix probe deferral handling
spi: omap2-mcspi: fix dma transfer for vmalloced buffer
spi: fix possible deadlock between internal bus locks and bus_lock_flag
spi: imx: Fix possible NULL pointer deref
spi: imx: only do necessary changes to ECSPIx_CONFIGREG
spi: rockchip: Spelling s/divsor/divisor/
rbd: use GFP_NOIO consistently for request allocations
As of 5a60e87603c4c533492c515b7f62578189b03c9c, RBD object request
allocations are made via rbd_obj_request_create() with GFP_NOIO.
However, subsequent OSD request allocations in rbd_osd_req_create*()
use GFP_ATOMIC.
With heavy page cache usage (e.g. OSDs running on same host as krbd
client), rbd_osd_req_create() order-1 GFP_ATOMIC allocations have been
observed to fail, where direct reclaim would have allowed GFP_NOIO
allocations to succeed.
There is no point on delaying the packet if we can't fit a single byte
of data on it anymore. So lets just reduce the threshold by the amount
that a data chunk with 4 bytes (rounding) would use.
Peter Ujfalusi [Tue, 5 Apr 2016 12:20:21 +0000 (15:20 +0300)]
dmaengine: omap-dma: Do not suppress interrupts for memcpy
If the client queues up more transfers the driver will not able to move to
the next transfer without knowing that the previous descriptor is
completed.
Peter Ujfalusi [Tue, 5 Apr 2016 12:20:20 +0000 (15:20 +0300)]
dmaengine: omap-dma: Fix polled channel completion detection and handling
When based on the CCR_ENABLE bit the channel is stopped we should not call
omap_dma_callback(), only change the return value to DMA_COMPLETE. Client
drivers will do the right thing to clean up the channel after the transfer
has been completed.
Check the CCR_ENABLE only if the channel is running and not paused since
pause in sDMA means that the channel is stopped.
This will fix one hard to reproduce race condition when the channel is
terminated during transfer (affecting cyclic operation).
Fixes: 1a7cf7b26f25 ("dmaengine: omap-dma: Handle cases when the channel is polled for completion") Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
Jason Gerecke [Mon, 4 Apr 2016 18:26:52 +0000 (11:26 -0700)]
HID: wacom: Support switching from vendor-defined device mode on G9 and G11
A tablet PC booted into Windows may have its pen/touch hardware switched
into "Wacom mode" similar to what we do with explicitly-supported hardware.
Some devices appear to maintain this state across reboots, preventing their
use with the generic HID driver. This patch adds support for detecting the
presence of the mode switch feature report used by devices based on the G9
and G11 chips and has the HID codepath always attempt to reset the device
back to sending standard HID reports.
Fixes: https://sourceforge.net/p/linuxwacom/bugs/307/ Fixes: https://sourceforge.net/p/linuxwacom/bugs/310/ Fixes: https://github.com/linuxwacom/input-wacom/issues/15 Co-authored-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jason Gerecke <[email protected]> Reviewed-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
Jason Gerecke [Mon, 4 Apr 2016 18:26:51 +0000 (11:26 -0700)]
HID: wacom: Initialize hid_data.inputmode to -1
Commit 5ae6e89 introduced hid_data.inputmode with a comment that it
would have the value -1 if undefined, but then forgot to actually
perform the initialization. Although this doesn't appear to have
caused any problems in practice, it should still be remedied.
Merge tag 'pinctrl-v4.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Here is a set of pin control fixes for the v4.6 series.
A bit bigger than what I hoped for, but all fixes are confined to
drivers, a few of them also targeted to stable.
Summary:
- On Super-H PFC (Renesas) controllers: only use dummies on legacy
systems. This fixes a serious ethernet regression on a Renesas
board.
- Pistachio: Fix errors in the pin table.
- Allwinner SunXi: fix the external interrupts to work.
- Intel: fix so the high level interrupts start working, and fix a
spurious interrupt issue.
- Qualcomm ipq4019: fix the number of GPIOs provided (bump to 100),
correct register offsets and handle GPIO mode properly.
- Revert the revert on the revert so that Xway has a .to_irq()
callback again.
- Minor fixes to errorpaths and debug info.
- A MAINTAINERS update"
* tag 'pinctrl-v4.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
Revert "Revert "pinctrl: lantiq: Implement gpio_chip.to_irq""
pinctrl: qcom: ipq4019: fix register offsets
pinctrl: qcom: ipq4019: fix the function enum for gpio mode
pinctrl: qcom: ipq4019: set ngpios to correct value
pinctrl: nomadik: fix pull debug print inversion
MAINTAINERS: pinctrl: samsung: Add two new maintainers
pinctrl: intel: implement gpio_irq_enable
pinctrl: intel: make the high level interrupt working
pinctrl: freescale: imx: fix bogus check of of_iomap() return value
pinctrl: sunxi: Fix A33 external interrupts not working
pinctrl: pistachio: fix mfio84-89 function description and pinmux.
pinctrl: sh-pfc: only use dummy states for non-DT platforms
Merge tag 'media/v4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fixes from Mauro Carvalho Chehab:
"Some bug fixes on au0828 and snd-usb-audio:
- the au0828+snd-usb-audio MC patch broke several things and produced
some race conditions. Better to revert the patches, and re-work on
them for a next version
- fix a regression at tuner disable links logic
- properly handle dev_state as a bitmask"
* tag 'media/v4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] Revert "[media] media: au0828 change to use Managed Media Controller API"
[media] Revert "[media] sound/usb: Use Media Controller API to share media resources"
[media] au0828: Fix dev_state handling
[media] au0828: fix au0828_v4l2_close() dev_state race condition
[media] media: au0828 fix to clear enable/disable/change source handlers
[media] v4l2-mc: cleanup a warning
[media] au0828: disable tuner links and cache tuner/decoder
Robin Murphy [Thu, 10 Mar 2016 19:28:12 +0000 (19:28 +0000)]
iommu/dma: Restore scatterlist offsets correctly
With the change to stashing just the IOVA-page-aligned remainder of the
CPU-page offset rather than the whole thing, the failure path in
__invalidate_sg() also needs tweaking to account for that in the case of
differing page sizes where the two offsets may not be equivalent.
Similarly in __finalise_sg(), lest the architecture-specific wrappers
later get the wrong address for cache maintenance on sync or unmap.
When a vCPU runs on a nohz_full core, the hrtimer used by
the lapic emulation code can be migrated to another core.
When this happens, it's possible to observe milisecond
latency when delivering timer IRQs to KVM guests.
The huge latency is mainly due to the fact that
apic_timer_fn() expects to run during a kvm exit. It
sets KVM_REQ_PENDING_TIMER and let it be handled on kvm
entry. However, if the timer fires on a different core,
we have to wait until the next kvm exit for the guest
to see KVM_REQ_PENDING_TIMER set.
This problem became visible after commit 9642d18ee. This
commit changed the timer migration code to always attempt
to migrate timers away from nohz_full cores. While it's
discussable if this is correct/desirable (I don't think
it is), it's clear that the lapic emulation code has
a requirement on firing the hrtimer in the same core
where it was started. This is achieved by making the
hrtimer pinned.
Lastly, note that KVM has code to migrate timers when a
vCPU is scheduled to run in different core. However, this
forced migration may fail. When this happens, we can have
the same problem. If we want 100% correctness, we'll have
to modify apic_timer_fn() to cause a kvm exit when it runs
on a different core than the vCPU. Not sure if this is
possible.
Here's a reproducer for the issue being fixed:
1. Set all cores but core0 to be nohz_full cores
2. Start a guest with a single vCPU
3. Trace apic_timer_fn() and kvm_inject_apic_timer_irqs()
You'll see that apic_timer_fn() will run in core0 while
kvm_inject_apic_timer_irqs() runs in a different core. If
you get both on core0, try running a program that takes 100%
of the CPU and pin it to core0 to force the vCPU out.
commit 1e133ab296f3 ("s390/mm: split arch/s390/mm/pgtable.c") dropped
some changes from commit a3a92c31bf0b ("KVM: s390: fix mismatch
between user and in-kernel guest limit") - this breaks KVM for some
memory sizes (kvm-s390: failed to commit memory region) like
exactly 2GB.
Arnd Bergmann [Tue, 15 Mar 2016 21:37:17 +0000 (22:37 +0100)]
iommu: provide of_xlate pointer unconditionally
iommu drivers that support the standard DT bindings use a of_xlate
callback pointer, but that is only part of struct iommu_ops when
CONFIG_OF_IOMMU is enabled, leading to build errors in randconfig
builds when that is not provided:
drivers/iommu/mtk_iommu.c:497:2: error: unknown field 'of_xlate' specified in initializer
.of_xlate = mtk_iommu_of_xlate,
^
drivers/iommu/mtk_iommu.c:497:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.of_xlate = mtk_iommu_of_xlate,
^~~~~~~~~~~~~~~~~~
drivers/iommu/mtk_iommu.c:497:14: note: (near initialization for 'mtk_iommu_ops.domain_get_attr')
We can work around it by adding more #ifdefs in each driver, but
it seems nicer to just allow setting the pointer even if it is
unused. This makes the driver code look nicer, and it gives better
compile-time coverage when test building on other architectures.
Hannes Reinecke [Fri, 1 Apr 2016 06:57:36 +0000 (08:57 +0200)]
scsi: Do not attach VPD to devices that don't support it
The patch "scsi: rescan VPD attributes" introduced a regression in which
devices that don't support VPD were being scanned for VPD attributes
anyway. This could cause issues for some devices and should be avoided
so the check for scsi_level has been moved out of scsi_add_lun and into
scsi_attach_vpd so that all callers will not scan VPD for devices that
don't support it.
Adrian Hunter [Mon, 4 Apr 2016 09:40:37 +0000 (12:40 +0300)]
mmc: sdhci-pci: Add support and PCI IDs for more Broxton host controllers
Add support and PCI IDs for more Broxton host controllers
Other BXT IDs were added in v4.4 so cc'ing stable. This patch
is dependent on commit 163cbe31e516 ("mmc: sdhci-pci: Fix card
detect race for Intel BXT/APL") but that is already in stable
since v4.4.4.
One of the VESA DMT timings in drm_dmt_modes[] is slightly off.
1024x768@43Hz (interlaced) vsync_end should be 776, not 772.
This brings it into line with the identical timings in edid_est_modes[].
projects / linux.git / log