aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-05-15drm/i915: Fix rawclk readout for g4xVille Syrjälä2-7/+9
Turns out our skills in decoding the CLKCFG register weren't good enough. On this particular elk the answer we got was 400 MHz when in reality the clock was running at 266 MHz, which then caused us to program a bogus AUX clock divider that caused all AUX communication to fail. Sadly the docs are now in bit heaven, so the fix will have to be based on empirical evidence. Using another elk machine I was able to frob the FSB frequency from the BIOS and see how it affects the CLKCFG register. The machine seesm to use a frequency of 266 MHz by default, and fortunately it still boot even with the 50% CPU overclock that we get when we bump the FSB up to 400 MHz. It turns out the actual FSB frequency and the register have no real link whatsoever. The register value is based on some straps or something, but fortunately those too can be configured from the BIOS on this board, although it doesn't seem to respect the settings 100%. In the end I was able to derive the following relationship: BIOS FSB / strap | CLKCFG ------------------------- 200 | 0x2 266 | 0x0 333 | 0x4 400 | 0x4 So only the 200 and 400 MHz cases actually match how we're currently decoding that register. But as the comment next to some of the defines says, we have been just guessing anyway. So let's fix things up so that at least the 266 MHz case will work correctly as that is actually the setting used by both the buggy machine and my test machine. The fact that 333 and 400 MHz BIOS settings result in the same register value is a little disappointing, as that means we can't tell them apart. However, according to the gmch datasheet for both elk and ctg 400 Mhz is not even a supported FSB frequency, so I'm going to make the assumption that we should decode it as 333 MHz instead. Cc: [email protected] Cc: Tomi Sarvela <[email protected]> Reported-by: Tomi Sarvela <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926 Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]> Tested-by: Tomi Sarvela <[email protected]> (cherry picked from commit 6f38123ecaac446312a63523b68df84ceb5a06ed) Signed-off-by: Jani Nikula <[email protected]>
2017-05-15drm/i915: Fix runtime PM for LPE audioVille Syrjälä2-4/+5
Not calling pm_runtime_enable() means that runtime PM can't be enabled at all via sysfs. So we definitely need to call it from somewhere. Calling it from the driver seems like a bad idea because it would have to be paired with a pm_runtime_disable() at driver unload time, otherwise the core gets upset. Also if there's no LPE audio driver loaded then we couldn't runtime suspend i915 either. So it looks like a better plan is to call it from i915 when we register the platform device. That seems to match how pci generally does things. I cargo culted the pm_runtime_forbid() and pm_runtime_set_active() calls from pci as well. The exposed runtime PM API is massive an thorougly misleading, so I don't actually know if this is how you're supposed to use the API or not. But it seems to work. I can now runtime suspend i915 again with or without the LPE audio driver loaded, and reloading the LPE audio driver also seems to work. Note that powertop won't auto-tune runtime PM for platform devices, which is a little annoying. So I'm not sure that leaving runtime PM in "on" mode by default is the best choice here. But I've left it like that for now at least. Also remove the comment about there not being much benefit from LPE audio runtime PM. Not allowing runtime PM blocks i915 runtime PM, which will also block s0ix, and that could have a measurable impact on power consumption. Cc: [email protected] Cc: Takashi Iwai <[email protected]> Cc: Pierre-Louis Bossart <[email protected]> Fixes: 0b6b524f3915 ("ALSA: x86: Don't enable runtime PM as default") Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Takashi Iwai <[email protected]> (cherry picked from commit 183c00350ccda86781f6695840e6c5f5b22efbd1) Signed-off-by: Jani Nikula <[email protected]>
2017-05-15drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messagesAnder Conselvan de Oliveira1-4/+3
The sequence in glk_dsi_device_ready() enters ULPS then waits until it is *not* active to then disable it. The correct sequence according to the spec is to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE bit is zero, i.e., ULPS is active, and then disable ULPS. Fixing the condition gets rid of the following spurious error messages: [drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable sequence") Cc: Deepak M <[email protected]> Cc: Madhav Chauhan <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: [email protected] Cc: <[email protected]> Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Madhav Chauhan <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3acbec03b3c51559d01c879e9564d9c9610fe8ce) Signed-off-by: Jani Nikula <[email protected]>
2017-05-15staging: rtl8723bs: remove re-positioned call to kfree in ↵Ian W MORRISON1-1/+0
os_dep/ioctl_cfg80211.c A re-positioned call to kfree() in drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c causes a segmentation error. This patch removed the kfree() call. Fixes 6557ddfec348 ("staging: rtl8723bs: Fix various errors in os_dep/ioctl_cfg80211.c") Signed-off-by: Ian W Morrison <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15s390/virtio: change virtio_feature_desc:features type to __le32Heiko Carstens1-1/+1
The feature member of virtio_feature_desc contains little endian values, given that it contents will be converted with le32_to_cpu(). The "wrong" __u32 type leads to the sparse warnings below. In order to avoid them, use the correct __le32 type instead. drivers/s390/virtio/virtio_ccw.c:749:14: warning: cast to restricted __le32 drivers/s390/virtio/virtio_ccw.c:762:28: warning: cast to restricted __le32 Acked-by: Halil Pasic <[email protected]> Acked-by: Cornelia Huck <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2017-05-15kvm: arm/arm64: Fix race in resetting stage2 PGDSuzuki K Poulose1-8/+8
In kvm_free_stage2_pgd() we check the stage2 PGD before holding the lock and proceed to take the lock if it is valid. And we unmap the page tables, followed by releasing the lock. We reset the PGD only after dropping this lock, which could cause a race condition where another thread waiting on or even holding the lock, could potentially see that the PGD is still valid and proceed to perform a stage2 operation and later encounter a NULL PGD. [223090.242280] Unable to handle kernel NULL pointer dereference at virtual address 00000040 [223090.262330] PC is at unmap_stage2_range+0x8c/0x428 [223090.262332] LR is at kvm_unmap_hva_handler+0x2c/0x3c [223090.262531] Call trace: [223090.262533] [<ffff0000080adb78>] unmap_stage2_range+0x8c/0x428 [223090.262535] [<ffff0000080adf40>] kvm_unmap_hva_handler+0x2c/0x3c [223090.262537] [<ffff0000080ace2c>] handle_hva_to_gpa+0xb0/0x104 [223090.262539] [<ffff0000080af988>] kvm_unmap_hva+0x5c/0xbc [223090.262543] [<ffff0000080a2478>] kvm_mmu_notifier_invalidate_page+0x50/0x8c [223090.262547] [<ffff0000082274f8>] __mmu_notifier_invalidate_page+0x5c/0x84 [223090.262551] [<ffff00000820b700>] try_to_unmap_one+0x1d0/0x4a0 [223090.262553] [<ffff00000820c5c8>] rmap_walk+0x1cc/0x2e0 [223090.262555] [<ffff00000820c90c>] try_to_unmap+0x74/0xa4 [223090.262557] [<ffff000008230ce4>] migrate_pages+0x31c/0x5ac [223090.262561] [<ffff0000081f869c>] compact_zone+0x3fc/0x7ac [223090.262563] [<ffff0000081f8ae0>] compact_zone_order+0x94/0xb0 [223090.262564] [<ffff0000081f91c0>] try_to_compact_pages+0x108/0x290 [223090.262569] [<ffff0000081d5108>] __alloc_pages_direct_compact+0x70/0x1ac [223090.262571] [<ffff0000081d64a0>] __alloc_pages_nodemask+0x434/0x9f4 [223090.262572] [<ffff0000082256f0>] alloc_pages_vma+0x230/0x254 [223090.262574] [<ffff000008235e5c>] do_huge_pmd_anonymous_page+0x114/0x538 [223090.262576] [<ffff000008201bec>] handle_mm_fault+0xd40/0x17a4 [223090.262577] [<ffff0000081fb324>] __get_user_pages+0x12c/0x36c [223090.262578] [<ffff0000081fb804>] get_user_pages_unlocked+0xa4/0x1b8 [223090.262579] [<ffff0000080a3ce8>] __gfn_to_pfn_memslot+0x280/0x31c [223090.262580] [<ffff0000080a3dd0>] gfn_to_pfn_prot+0x4c/0x5c [223090.262582] [<ffff0000080af3f8>] kvm_handle_guest_abort+0x240/0x774 [223090.262584] [<ffff0000080b2bac>] handle_exit+0x11c/0x1ac [223090.262586] [<ffff0000080ab99c>] kvm_arch_vcpu_ioctl_run+0x31c/0x648 [223090.262587] [<ffff0000080a1d78>] kvm_vcpu_ioctl+0x378/0x768 [223090.262590] [<ffff00000825df5c>] do_vfs_ioctl+0x324/0x5a4 [223090.262591] [<ffff00000825e26c>] SyS_ioctl+0x90/0xa4 [223090.262595] [<ffff000008085d84>] el0_svc_naked+0x38/0x3c This patch moves the stage2 PGD manipulation under the lock. Reported-by: Alexander Graf <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Radim Krčmář <[email protected]> Reviewed-by: Christoffer Dall <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Signed-off-by: Suzuki K Poulose <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2017-05-15Merge tag 'gvt-fixes-2017-05-11' of https://github.com/01org/gvt-linux into ↵Jani Nikula3-3/+10
drm-intel-fixes gvt-fixes-2017-05-11 - vGPU scheduler performance regression fix (Ping) - bypass in-context mmio restore (Chuanxiao) - one typo fix (Colin) Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-05-15USB: serial: io_ti: fix div-by-zero in set_termiosJohan Hovold1-1/+4
Fix a division-by-zero in set_termios when debugging is enabled and a high-enough speed has been requested so that the divisor value becomes zero. Instead of just fixing the offending debug statement, cap the baud rate at the base as a zero divisor value also appears to crash the firmware. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <[email protected]> # 2.6.12 Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2017-05-15USB: serial: mct_u232: fix big-endian baud-rate handlingJohan Hovold1-1/+1
Drop erroneous cpu_to_le32 when setting the baud rate, something which corrupted the divisor on big-endian hosts. Found using sparse: warning: incorrect type in argument 1 (different base types) expected unsigned int [unsigned] [usertype] val got restricted __le32 [usertype] <noident> Fixes: af2ac1a091bc ("USB: serial mct_usb232: move DMA buffers to heap") Cc: stable <[email protected]> # 2.6.34 Reviewed-by: Greg Kroah-Hartman <[email protected]> Acked-By: Pete Zaitcev <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2017-05-15USB: serial: ir-usb: fix big-endian baud-rate debug printkJohan Hovold1-9/+12
Add missing endianness conversion when printing the supported baud rates. Found using sparse: warning: restricted __le16 degrades to integer Fixes: e0d795e4f36c ("usb: irda: cleanup on ir-usb module") Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2017-05-15staging: rtl8192e: GetTs Fix invalid TID 7 warning.Malcolm Priestley1-11/+4
TID 7 is a valid value for QoS IEEE 802.11e. The switch statement that follows states 7 is valid. Remove function IsACValid and use the default case to filter invalid TIDs. Signed-off-by: Malcolm Priestley <[email protected]> Cc: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: rtl8192e: rtl92e_get_eeprom_size Fix read size of EPROM_CMD.Malcolm Priestley1-1/+1
EPROM_CMD is 2 byte aligned on PCI map so calling with rtl92e_readl will return invalid data so use rtl92e_readw. The device is unable to select the right eeprom type. Signed-off-by: Malcolm Priestley <[email protected]> Cc: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: rtl8192e: fix 2 byte alignment of register BSSIDR.Malcolm Priestley1-4/+5
BSSIDR has two byte alignment on PCI ioremap correct the write by swapping to 16 bits first. This fixes a problem that the device associates fail because the filter is not set correctly. Signed-off-by: Malcolm Priestley <[email protected]> Cc: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: rtl8192e: rtl92e_fill_tx_desc fix write to mapped out memory.Malcolm Priestley1-4/+9
The driver attempts to alter memory that is mapped to PCI device. This is because tx_fwinfo_8190pci points to skb->data Move the pci_map_single to when completed buffer is ready to be mapped with psdec is empty to drop on mapping error. Signed-off-by: Malcolm Priestley <[email protected]> Cc: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: vc04_services: Fix bulk cache maintenancePhil Elwell1-12/+19
vchiq_arm supports transfers less than one page and at arbitrary alignment, using the dma-mapping API to perform its cache maintenance (even though the VPU drives the DMA hardware). Read (DMA_FROM_DEVICE) operations use cache invalidation for speed, falling back to clean+invalidate on partial cache lines, with writes (DMA_TO_DEVICE) using flushes. If a read transfer has ends which aren't page-aligned, performing cache maintenance as if they were whole pages can lead to memory corruption since the partial cache lines at the ends (and any cache lines before or after the transfer area) will be invalidated. This bug was masked until the disabling of the cache flush in flush_dcache_page(). Honouring the requested transfer start- and end-points prevents the corruption. Fixes: cf9caf192988 ("staging: vc04_services: Replace dmac_map_area with dmac_map_sg") Signed-off-by: Phil Elwell <[email protected]> Cc: stable <[email protected]> # 4.10 Reported-by: Stefan Wahren <[email protected]> Tested-by: Stefan Wahren <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: ccree: remove extraneous spin_unlock_bh() in error handlerIan Chard1-1/+0
An early error handler in send_request() tries to release a spinlock, but the lock isn't acquired until the loop below it is entered. Signed-off-by: Ian Chard <[email protected]> Acked-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: typec: Fix sparse warnings about incorrect typesGuru Das Srinagesh1-2/+2
Fix the following sparse warnings about incorrect type usage: fusb302.c:1028:32: warning: incorrect type in argument 1 (different base types) fusb302.c:1028:32: expected unsigned short [unsigned] [usertype] header fusb302.c:1028:32: got restricted __le16 const [usertype] header fusb302.c:1484:32: warning: incorrect type in argument 1 (different base types) fusb302.c:1484:32: expected unsigned short [unsigned] [usertype] header fusb302.c:1484:32: got restricted __le16 [usertype] header Signed-off-by: Guru Das Srinagesh <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: typec: fusb302: do not free gpio from managed resourceRui Miguel Silva1-2/+0
When allocating a gpio using the managed resource devm_, we can avoid freeing it manually. But even if we did it we should use devm_gpio_free. So, just remove the free of the gpio in the error path. Signed-off-by: Rui Miguel Silva <[email protected]> Acked-by: Yueyao Zhu <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15KVM: arm/arm64: vgic-v3: Use PREbits to infer the number of ICH_APxRn_EL2 ↵Marc Zyngier1-9/+9
registers The GICv3 documentation is extremely confusing, as it talks about the number of priorities represented by the ICH_APxRn_EL2 registers, while it should really talk about the number of preemption levels. This leads to a bug where we may access undefined ICH_APxRn_EL2 registers, since PREbits is allowed to be smaller than PRIbits. Thankfully, nobody seem to have taken this path so far... The fix is to use ICH_VTR_EL2.PREbits instead. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2017-05-15KVM: arm/arm64: vgic-v3: Do not use Active+Pending state for a HW interruptMarc Zyngier1-0/+7
When an interrupt is injected with the HW bit set (indicating that deactivation should be propagated to the physical distributor), special care must be taken so that we never mark the corresponding LR with the Active+Pending state (as the pending state is kept in the physycal distributor). Cc: [email protected] Fixes: 59529f69f504 ("KVM: arm/arm64: vgic-new: Add GICv3 world switch backend") Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2017-05-15KVM: arm/arm64: vgic-v2: Do not use Active+Pending state for a HW interruptMarc Zyngier1-0/+7
When an interrupt is injected with the HW bit set (indicating that deactivation should be propagated to the physical distributor), special care must be taken so that we never mark the corresponding LR with the Active+Pending state (as the pending state is kept in the physycal distributor). Cc: [email protected] Fixes: 140b086dd197 ("KVM: arm/arm64: vgic-new: Add GICv2 world switch backend") Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2017-05-15powerpc/tm: Fix FP and VMX register corruptionMichael Neuling1-0/+19
In commit dc3106690b20 ("powerpc: tm: Always use fp_state and vr_state to store live registers"), a section of code was removed that copied the current state to checkpointed state. That code should not have been removed. When an FP (Floating Point) unavailable is taken inside a transaction, we need to abort the transaction. This is because at the time of the tbegin, the FP state is bogus so the state stored in the checkpointed registers is incorrect. To fix this, we treclaim (to get the checkpointed GPRs) and then copy the thread_struct FP live state into the checkpointed state. We then trecheckpoint so that the FP state is correctly restored into the CPU. The copying of the FP registers from live to checkpointed is what was missing. This simplifies the logic slightly from the original patch. tm_reclaim_thread() will now always write the checkpointed FP state. Either the checkpointed FP state will be written as part of the actual treclaim (in tm.S), or it'll be a copy of the live state. Which one we use is based on MSR[FP] from userspace. Similarly for VMX. Fixes: dc3106690b20 ("powerpc: tm: Always use fp_state and vr_state to store live registers") Cc: [email protected] # 4.9+ Signed-off-by: Michael Neuling <[email protected]> Reviewed-by: [email protected] Signed-off-by: Michael Ellerman <[email protected]>
2017-05-15arm: KVM: Do not use stack-protector to compile HYP codeMarc Zyngier1-0/+2
We like living dangerously. Nothing explicitely forbids stack-protector to be used in the HYP code, while distributions routinely compile their kernel with it. We're just lucky that no code actually triggers the instrumentation. Let's not try our luck for much longer, and disable stack-protector for code living at HYP. Cc: [email protected] Signed-off-by: Marc Zyngier <[email protected]> Acked-by: Christoffer Dall <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2017-05-15powerpc/modules: If mprofile-kernel is enabled add it to vermagicMichael Ellerman1-0/+4
On powerpc we can build the kernel with two different ABIs for mcount(), which is used by ftrace. Kernels built with one ABI do not know how to load modules built with the other ABI. The new style ABI is called "mprofile-kernel", for want of a better name. Currently if we build a module using the old style ABI, and the kernel with mprofile-kernel, when we load the module we'll oops something like: # insmod autofs4-no-mprofile-kernel.ko ftrace-powerpc: Unexpected instruction f8810028 around bl _mcount ------------[ cut here ]------------ WARNING: CPU: 6 PID: 3759 at ../kernel/trace/ftrace.c:2024 ftrace_bug+0x2b8/0x3c0 CPU: 6 PID: 3759 Comm: insmod Not tainted 4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269 #11 ... NIP [c0000000001eaa48] ftrace_bug+0x2b8/0x3c0 LR [c0000000001eaff8] ftrace_process_locs+0x4a8/0x590 Call Trace: alloc_pages_current+0xc4/0x1d0 (unreliable) ftrace_process_locs+0x4a8/0x590 load_module+0x1c8c/0x28f0 SyS_finit_module+0x110/0x140 system_call+0x38/0xfc ... ftrace failed to modify [<d000000002a31024>] 0xd000000002a31024 actual: 35:65:00:48 We can avoid this by including in the vermagic whether the kernel/module was built with mprofile-kernel. Which results in: # insmod autofs4-pg.ko autofs4: version magic '4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269 SMP mod_unload modversions ' should be '4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269-dirty SMP mod_unload modversions mprofile-kernel' insmod: ERROR: could not insert module autofs4-pg.ko: Invalid module format Fixes: 8c50b72a3b4f ("powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel") Signed-off-by: Michael Ellerman <[email protected]> Acked-by: Balbir Singh <[email protected]> Acked-by: Jessica Yu <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2017-05-15arm64: KVM: Do not use stack-protector to compile EL2 codeMarc Zyngier1-0/+2
We like living dangerously. Nothing explicitely forbids stack-protector to be used in the EL2 code, while distributions routinely compile their kernel with it. We're just lucky that no code actually triggers the instrumentation. Let's not try our luck for much longer, and disable stack-protector for code living at EL2. Cc: [email protected] Signed-off-by: Marc Zyngier <[email protected]> Acked-by: Christoffer Dall <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2017-05-15staging: typec: tcpm: Fix Port Power Role field in PS_RDY messagesGuenter Roeck1-2/+16
PS_RDY messages sent during power swap sequences are expected to reflect the new power role. Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: typec: tcpm: Respond to Discover Identity commandsGuenter Roeck3-1/+33
If the lower level driver provided a list of VDOs in its configuration data, send it to the partner as response to a Discover Identity command if in device mode (UFP). Cc: Yueyao Zhu <[email protected]> Originally-from: Puma Hsu <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: typec: tcpm: Set correct flags in PD request messagesGuenter Roeck1-2/+1
We do support USB PD communication, and devices supported by this driver typically use USB power for purposes other than USB communication. Originally-from: Puma Hsu <[email protected]> Cc: Yueyao Zhu <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: typec: tcpm: Drop duplicate PD messagesGuenter Roeck2-0/+39
Per USB PD standard, we have to drop duplicate PD messages. We can not expect lower protocol layers to drop such messages, since lower layers don't know if a message was dropped somewhere else in the stack. Originally-from: Puma Hsu <[email protected]> Cc: Yueyao Zhu <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: typec: fusb302: Fix chip->vbus_present init valueYueyao Zhu1-1/+1
FUSB_REG_STATUS0 & FUSB_REG_STATUS0_VBUSOK = 0x40 & 0x80 is always zero. Fix the code to what it is intended to be: check the VBUSOK bit of the value read from address FUSB_REG_STATUS0. Reported-by: Dan Carpenter <[email protected]> Cc: Guenter Roeck <[email protected]> Signed-off-by: Yueyao Zhu <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: typec: fusb302: Fix module autoloadJavier Martinez Canillas1-0/+2
If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the OF and I2C device ID table entries as module aliases, using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/staging/typec/fusb302/fusb302.ko | grep alias $ After this patch: $ modinfo drivers/staging/typec/fusb302/fusb302.ko | grep alias alias: of:N*T*Cfcs,fusb302C* alias: of:N*T*Cfcs,fusb302 alias: i2c:typec_fusb302 Signed-off-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: typec: tcpci: declare private structure as staticOlivier Leveque1-1/+1
This fixes a sparse warning regarding an undeclared symbol. Since the structure tcpci_tcpc_config is private to tcpci.c, it should be declared as static. Signed-off-by: Olivier Leveque <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging: MAINTAINERS: add GBY as ccree maintainerGilad Ben-Yossef1-0/+8
I work for Arm on maintaining the TrustZone CryptoCell driver. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15staging/android/ion: remove useless document fileYisheng Xie3-83/+0
After commit 9828282e33a0 ("staging: android: ion: Remove old platform support"), the document about devicetree of ion is no need anymore, so just remove it. Signed-off-by: Yisheng Xie <[email protected]> Acked-by: Laura Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-15USB: serial: ftdi_sio: fix setting latency for unprivileged usersAnthony Mallet1-1/+1
Commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag") enables unprivileged users to set the FTDI latency timer, but there was a logic flaw that skipped sending the corresponding USB control message to the device. Specifically, the device latency timer would not be updated until next open, something which was later also inadvertently broken by commit c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port probe"). A recent commit c6dce2626606 ("USB: serial: ftdi_sio: fix extreme low-latency setting") disabled the low-latency mode by default so we now need this fix to allow unprivileged users to again enable it. Signed-off-by: Anthony Mallet <[email protected]> [johan: amend commit message] Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag") Fixes: c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port probe"). Cc: stable <[email protected]> # 2.6.31 Signed-off-by: Johan Hovold <[email protected]>
2017-05-15sched/core: Call __schedule() from do_idle() without enabling preemptionSteven Rostedt (VMware)3-1/+28
I finally got around to creating trampolines for dynamically allocated ftrace_ops with using synchronize_rcu_tasks(). For users of the ftrace function hook callbacks, like perf, that allocate the ftrace_ops descriptor via kmalloc() and friends, ftrace was not able to optimize the functions being traced to use a trampoline because they would also need to be allocated dynamically. The problem is that they cannot be freed when CONFIG_PREEMPT is set, as there's no way to tell if a task was preempted on the trampoline. That was before Paul McKenney implemented synchronize_rcu_tasks() that would make sure all tasks (except idle) have scheduled out or have entered user space. While testing this, I triggered this bug: BUG: unable to handle kernel paging request at ffffffffa0230077 ... RIP: 0010:0xffffffffa0230077 ... Call Trace: schedule+0x5/0xe0 schedule_preempt_disabled+0x18/0x30 do_idle+0x172/0x220 What happened was that the idle task was preempted on the trampoline. As synchronize_rcu_tasks() ignores the idle thread, there's nothing that lets ftrace know that the idle task was preempted on a trampoline. The idle task shouldn't need to ever enable preemption. The idle task is simply a loop that calls schedule or places the cpu into idle mode. In fact, having preemption enabled is inefficient, because it can happen when idle is just about to call schedule anyway, which would cause schedule to be called twice. Once for when the interrupt came in and was returning back to normal context, and then again in the normal path that the idle loop is running in, which would be pointless, as it had already scheduled. The only reason schedule_preempt_disable() enables preemption is to be able to call sched_submit_work(), which requires preemption enabled. As this is a nop when the task is in the RUNNING state, and idle is always in the running state, there's no reason that idle needs to enable preemption. But that means it cannot use schedule_preempt_disable() as other callers of that function require calling sched_submit_work(). Adding a new function local to kernel/sched/ that allows idle to call the scheduler without enabling preemption, fixes the synchronize_rcu_tasks() issue, as well as removes the pointless spurious schedule calls caused by interrupts happening in the brief window where preemption is enabled just before it calls schedule. Reviewed: Thomas Gleixner <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-05-15usb: serial: option: add Telit ME910 supportDaniele Palmas1-0/+8
This patch adds support for Telit ME910 PID 0x1100. Signed-off-by: Daniele Palmas <[email protected]> Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2017-05-15ARM: KVM: Fix tracepoint generation after move to virt/kvm/arm/Marc Zyngier2-4/+5
Moving most of the shared code to virt/kvm/arm had for consequence that KVM/ARM doesn't build anymore, because the code that used to define the tracepoints is now somewhere else. Fix this by defining CREATE_TRACE_POINTS in coproc.c, and clean-up trace.h as well. Fixes: 35d2d5d490e2 ("KVM: arm/arm64: Move shared files to virt/kvm/arm") Reported-by: Arnd Bergmann <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2017-05-14dm cache policy smq: don't do any writebacks unless IDLEJoe Thornber1-5/+4
If there are no clean blocks to be demoted the writeback will be triggered at that point. Preemptively writing back can hurt high IO load scenarios. Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2017-05-14dm cache: simplify the IDLE vs BUSY state calculationJoe Thornber1-6/+3
Drop the MODERATE state since it wasn't buying us much. Also, in check_migrations(), prepare for the next commit ("dm cache policy smq: don't do any writebacks unless IDLE") by deferring to the policy to make the final decision on whether writebacks can be serviced. Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2017-05-14dm cache: track all IO to the cache rather than just the origin device's IOJoe Thornber1-8/+7
IO tracking used to throttle writebacks when the origin device is busy. Even if all the IO is going to the fast device, writebacks can significantly degrade performance. So track all IO to gauge whether the cache is busy or not. Otherwise, synthetic IO tests (e.g. fio) that might send all IO to the fast device wouldn't cause writebacks to get throttled. Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2017-05-14dm cache policy smq: stop preemptively demoting blocksJoe Thornber1-12/+5
It causes a lot of churn if the working set's size is close to the fast device's size. Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2017-05-14dm cache policy smq: put newly promoted entries at the top of the multiqueueJoe Thornber1-0/+1
This stops entries bouncing in and out of the cache quickly. Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2017-05-14dm cache policy smq: be more aggressive about triggering a writebackJoe Thornber1-1/+1
If there are no clean entries to demote we really want to writeback immediately. Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2017-05-14dm cache policy smq: only demote entries in bottom half of the clean multiqueueJoe Thornber1-1/+1
Heavy IO load may mean there are very few clean blocks in the cache, and we risk demoting entries that get hit a lot. Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2017-05-14dm cache: fix incorrect 'idle_time' reset in IO trackerJoe Thornber1-0/+3
Some bios have no payload (eg, a FLUSH), don't reset the idle_time when these come in. Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2017-05-15soc: imx: add PM dependency for IMX7_PM_DOMAINSArnd Bergmann1-1/+2
The new pm domain driver causes a build failure when CONFIG_PM is not set: warning: (IMX7_PM_DOMAINS) selects PM_GENERIC_DOMAINS which has unmet direct dependencies (PM) drivers/base/power/domain_governor.c: In function 'default_suspend_ok': drivers/base/power/domain_governor.c:75:17: error: 'struct dev_pm_info' has no member named 'ignore_children' This adds a dependency to ensure that we don't attempt to build the driver without CONFIG_PM. Fixes: 03aa12629fc4 ("soc: imx: Add GPCv2 power gating driver") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2017-05-15ARM: dts: imx6sx-sdb: Remove OPP overrideLeonard Crestez1-17/+0
The board file for imx6sx-sdb overrides cpufreq operating points to use higher voltages. This is done because the board has a shared rail for VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the shared voltage needs to be a value suitable for both ARM and SOC. This only applies to LDO bypass mode, a feature not present in upstream. When LDOs are enabled the effect is to use higher voltages than necessary for no good reason. Setting these higher voltages can make some boards fail to boot with ugly semi-random crashes reminiscent of memory corruption. These failures only happen on board rev. C, rev. B is reported to still work. Signed-off-by: Leonard Crestez <[email protected]> Fixes: 54183bd7f766 ("ARM: imx6sx-sdb: add revb board and make it default") Cc: [email protected] Signed-off-by: Shawn Guo <[email protected]>
2017-05-15ARM: dts: imx53-qsrb: Pulldown PMIC IRQ pinFabio Estevam1-1/+1
Currently the following errors are seen: [ 14.015056] mc13xxx 0-0008: Failed to read IRQ status: -6 [ 27.321093] mc13xxx 0-0008: Failed to read IRQ status: -6 [ 27.411681] mc13xxx 0-0008: Failed to read IRQ status: -6 [ 27.456281] mc13xxx 0-0008: Failed to read IRQ status: -6 [ 30.527106] mc13xxx 0-0008: Failed to read IRQ status: -6 [ 36.596900] mc13xxx 0-0008: Failed to read IRQ status: -6 Also when reading the interrupts via 'cat /proc/interrupts' the PMIC GPIO interrupt counter does not stop increasing. The reason for the storm of interrupts is that the PUS field of register IOMUXC_SW_PAD_CTL_PAD_CSI0_DAT5 is currently configured as: 10 : 100k pullup and the PMIC interrupt is being registered as IRQ_TYPE_LEVEL_HIGH type, which is the correct type as per the MC34708 datasheet. Use the default power on value for the IOMUX, which sets PUS field as: 00: 360k pull down This prevents the spurious PMIC interrupts from happening. Commit e1ffceb078c6 ("ARM: imx53: qsrb: fix PMIC interrupt level") correctly described the irq type as IRQ_TYPE_LEVEL_HIGH, but missed to update the IOMUX of the PMIC GPIO as pull down. Fixes: e1ffceb078c6 ("ARM: imx53: qsrb: fix PMIC interrupt level") Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2017-05-15security: Grammar s/allocates/allocated/Geert Uytterhoeven1-1/+1
Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: James Morris <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.