aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-06-04ASoC: max98090: remove 24-bit format support if RJ is 0Yu-Hsuan Hsu1-0/+16
The supported formats are S16_LE and S24_LE now. However, by datasheet of max98090, S24_LE is only supported when it is in the right justified mode. We should remove 24-bit format if it is not in that mode to avoid triggering error. Signed-off-by: Yu-Hsuan Hsu <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-04ASoC: da7219: Fix build error without CONFIG_I2CYueHaibing1-1/+1
Fix gcc build error while CONFIG_I2C is not set sound/soc/codecs/da7219.c:2640:1: warning: data definition has no type or storage class module_i2c_driver(da7219_i2c_driver); ^~~~~~~~~~~~~~~~~ sound/soc/codecs/da7219.c:2640:1: error: type defaults to int in declaration of module_i2c_driver [-Werror=implicit-int] sound/soc/codecs/da7219.c:2640:1: warning: parameter names (without types) in function declaration sound/soc/codecs/da7219.c:2629:26: warning: da7219_i2c_driver defined but not used [-Wunused-variable] Reported-by: Hulk Robot <[email protected]> Fixes: 6d817c0e9fd7 ("ASoC: codecs: Add da7219 codec driver") Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-04ASoC: SOF: Intel: hda: Fix COMPILE_TEST build errorYueHaibing1-0/+4
while building without PCI: sound/soc/sof/intel/hda.o: In function `hda_dsp_probe': hda.c:(.text+0x79c): undefined reference to `pci_ioremap_bar' hda.c:(.text+0x79c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `pci_ioremap_bar' hda.c:(.text+0x7c4): undefined reference to `pci_ioremap_bar' hda.c:(.text+0x7c4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `pci_ioremap_bar' Reported-by: Hulk Robot <[email protected]> Fixes: e13ef82a9ab8 ("ASoC: SOF: add COMPILE_TEST for PCI options") Signed-off-by: YueHaibing <[email protected]> Acked-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-04drm/arm/hdlcd: Allow a bit of clock toleranceRobin Murphy1-1/+2
On the Arm Juno platform, the HDLCD pixel clock is constrained to 250KHz resolution in order to avoid the tiny System Control Processor spending aeons trying to calculate exact PLL coefficients. This means that modes like my oddball 1600x1200 with 130.89MHz clock get rejected since the rate cannot be matched exactly. In practice, though, this mode works quite happily with the clock at 131MHz, so let's relax the check to allow a little bit of slop. Signed-off-by: Robin Murphy <[email protected]> Signed-off-by: Liviu Dudau <[email protected]>
2019-06-04drm/arm/hdlcd: Actually validate CRTC modesRobin Murphy1-6/+5
Rather than allowing any old mode through, then subsequently refusing unmatchable clock rates in atomic_check when it's too late to back out and pick a different mode, let's do that validation up-front where it will cause unsupported modes to be correctly pruned in the first place. This also eliminates an issue whereby a perceived clock rate of 0 would cause atomic disable to fail and prevent the module from being unloaded. Signed-off-by: Robin Murphy <[email protected]> Signed-off-by: Liviu Dudau <[email protected]>
2019-06-04drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 timesWen He1-1/+12
This patch trying to fix monitor freeze issue caused by drm error 'flip_done timed out' on LS1028A platform. this set try is make a loop around the second setting CVAL and try like 5 times before giveing up. Signed-off-by: Wen He <[email protected]> Signed-off-by: Liviu Dudau <[email protected]>
2019-06-04drm/komeda: fixing of DMA mapping sg segment warningLowry Li (Arm Technology China)2-0/+6
Fixing the DMA mapping sg segment warning, which shows "DMA-API: mapping sg segment longer than device claims to support [len=921600] [max=65536]". Fixed by setting the max segment size at Komeda driver. This patch depends on: - https://patchwork.freedesktop.org/series/54448/ - https://patchwork.freedesktop.org/series/54449/ - https://patchwork.freedesktop.org/series/54450/ - https://patchwork.freedesktop.org/series/58976/ Changes since v1: - Adds member description - Adds patch denpendency in the comment Signed-off-by: Lowry Li (Arm Technology China) <[email protected]> Reviewed-by: James Qian Wang (Arm Technology China) <[email protected]> Reviewed-by: Ayan Kumar Halder <[email protected]> Signed-off-by: Liviu Dudau <[email protected]>
2019-06-04habanalabs: Read upper bits of trace buffer from RWPHITomer Tayar1-2/+12
The trace buffer address is 40 bits wide. The end of the buffer is set in the RWP register (lower 32 bits), and in the RWPHI register (upper 8 bits). Currently only the lower 32 bits are read, and this patch fixes it and concatenates the upper 8 bits to the output address. Signed-off-by: Tomer Tayar <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2019-06-04drm: don't block fb changes for async plane updatesHelen Koike2-10/+20
In the case of a normal sync update, the preparation of framebuffers (be it calling drm_atomic_helper_prepare_planes() or doing setups with drm_framebuffer_get()) are performed in the new_state and the respective cleanups are performed in the old_state. In the case of async updates, the preparation is also done in the new_state but the cleanups are done in the new_state (because updates are performed in place, i.e. in the current state). The current code blocks async udpates when the fb is changed, turning async updates into sync updates, slowing down cursor updates and introducing regressions in igt tests with errors of type: "CRITICAL: completed 97 cursor updated in a period of 30 flips, we expect to complete approximately 15360 updates, with the threshold set at 7680" Fb changes in async updates were prevented to avoid the following scenario: - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1 - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2 - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong) Where we have a single call to prepare fb2 but double cleanup call to fb2. To solve the above problems, instead of blocking async fb changes, we place the old framebuffer in the new_state object, so when the code performs cleanups in the new_state it will cleanup the old_fb and we will have the following scenario instead: - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1 - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 Where calls to prepare/cleanup are balanced. Cc: <[email protected]> # v4.14+ Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates") Suggested-by: Boris Brezillon <[email protected]> Signed-off-by: Helen Koike <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-06-04drm/vc4: fix fb references in async updateHelen Koike1-1/+1
Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Cc: <[email protected]> # v4.19+ Fixes: 539c320bfa97 ("drm/vc4: update cursors asynchronously through atomic") Suggested-by: Boris Brezillon <[email protected]> Signed-off-by: Helen Koike <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-06-04drm/msm: fix fb references in async updateHelen Koike1-0/+4
Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Cc: <[email protected]> # v4.14+ Fixes: 224a4c970987 ("drm/msm: update cursors asynchronously through atomic") Suggested-by: Boris Brezillon <[email protected]> Signed-off-by: Helen Koike <[email protected]> Acked-by: Rob Clark <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-06-04drm/amd: fix fb references in async updateHelen Koike1-2/+1
Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Cc: <[email protected]> # v4.20+ Fixes: 674e78acae0d ("drm/amd/display: Add fast path for cursor plane updates") Suggested-by: Boris Brezillon <[email protected]> Signed-off-by: Helen Koike <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-06-04drm/rockchip: fix fb references in async updateHelen Koike1-25/+26
In the case of async update, modifications are done in place, i.e. in the current plane state, so the new_state is prepared and the new_state is cleaned up (instead of the old_state, unlike what happens in a normal sync update). To cleanup the old_fb properly, it needs to be placed in the new_state in the end of async_update, so cleanup call will unreference the old_fb correctly. Also, the previous code had a: plane_state = plane->funcs->atomic_duplicate_state(plane); ... swap(plane_state, plane->state); if (plane->state->fb && plane->state->fb != new_state->fb) { ... } Which was wrong, as the fb were just assigned to be equal, so this if statement nevers evaluates to true. Another details is that the function drm_crtc_vblank_get() can only be called when vop->is_enabled is true, otherwise it has no effect and trows a WARN_ON(). Calling drm_atomic_set_fb_for_plane() (which get a referent of the new fb and pus the old fb) is not required, as it is taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Fixes: 15609559a834 ("drm/rockchip: update cursors asynchronously through atomic.") Cc: <[email protected]> # v4.20+ Signed-off-by: Helen Koike <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-06-03xen-blkfront: switch kcalloc to kvcalloc for large array allocationRoger Pau Monne1-19/+19
There's no reason to request physically contiguous memory for those allocations. [boris: added CC to stable] Cc: [email protected] Reported-by: Ian Jackson <[email protected]> Signed-off-by: Roger Pau Monné <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: Boris Ostrovsky <[email protected]>
2019-06-04drm/mediatek: call mtk_dsi_stop() after mtk_drm_crtc_atomic_disable()Hsin-Yi Wang1-1/+9
mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which needs ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called, ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called after last irq, it will timeout with this message: "vblank wait timed out on crtc 0". This happens sometimes when turning off the screen. In drm_atomic_helper.c#disable_outputs(), the calling sequence when turning off the screen is: 1. mtk_dsi_encoder_disable() --> mtk_output_dsi_disable() --> mtk_dsi_stop(); /* sometimes make vblank timeout in atomic_disable */ --> mtk_dsi_poweroff(); 2. mtk_drm_crtc_atomic_disable() --> drm_crtc_wait_one_vblank(); ... --> mtk_dsi_ddp_stop() --> mtk_dsi_poweroff(); mtk_dsi_poweroff() has reference count design, change to make mtk_dsi_stop() called in mtk_dsi_poweroff() when refcount is 0. Fixes: 0707632b5bac ("drm/mediatek: update DSI sub driver flow for sending commands to panel") Signed-off-by: Hsin-Yi Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-06-04drm/mediatek: clear num_pipes when unbind driverHsin-Yi Wang1-0/+1
num_pipes is used for mutex created in mtk_drm_crtc_create(). If we don't clear num_pipes count, when rebinding driver, the count will be accumulated. From mtk_disp_mutex_get(), there can only be at most 10 mutex id. Clear this number so it starts from 0 in every rebind. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsin-Yi Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-06-04drm/mediatek: call drm_atomic_helper_shutdown() when unbinding driverHsin-Yi Wang1-0/+1
shutdown all CRTC when unbinding drm driver. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsin-Yi Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-06-04drm/mediatek: unbind components in mtk_drm_unbind()Hsin-Yi Wang1-5/+1
Unbinding components (i.e. mtk_dsi and mtk_disp_ovl/rdma/color) will trigger master(mtk_drm)'s .unbind(), and currently mtk_drm's unbind won't actually unbind components. During the next bind, mtk_drm_kms_init() is called, and the components are added back. .unbind() should call mtk_drm_kms_deinit() to unbind components. And since component_master_del() in .remove() will trigger .unbind(), which will also unregister device, it's fine to remove original functions called here. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsin-Yi Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-06-04drm/mediatek: fix unbind functionsHsin-Yi Wang1-0/+2
detatch panel in mtk_dsi_destroy_conn_enc(), since .bind will try to attach it again. Fixes: 2e54c14e310f ("drm/mediatek: Add DSI sub driver") Signed-off-by: Hsin-Yi Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-06-03net: sfp: read eeprom in maximum 16 byte incrementsRussell King1-4/+20
Some SFP modules do not like reads longer than 16 bytes, so read the EEPROM in chunks of 16 bytes at a time. This behaviour is not specified in the SFP MSAs, which specifies: "The serial interface uses the 2-wire serial CMOS E2PROM protocol defined for the ATMEL AT24C01A/02/04 family of components." and "As long as the SFP+ receives an acknowledge, it shall serially clock out sequential data words. The sequence is terminated when the host responds with a NACK and a STOP instead of an acknowledge." We must avoid breaking a read across a 16-bit quantity in the diagnostic page, thankfully all 16-bit quantities in that page are naturally aligned. Signed-off-by: Russell King <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-06-03selftests: set sysctl bc_forwarding properly in router_broadcast.shXin Long1-1/+4
sysctl setting bc_forwarding for $rp2 is needed when ping_test_from h2, otherwise the bc packets from $rp2 won't be forwarded. This patch is to add this setting for $rp2. Also, as ping_test_from does grep "$from" only, which could match some unexpected output, some test case doesn't really work, like: # ping_test_from $h2 198.51.200.255 198.51.200.2 PING 198.51.200.255 from 198.51.100.2 veth3: 56(84) bytes of data. 64 bytes from 198.51.100.1: icmp_seq=1 ttl=64 time=0.336 ms When doing grep $form (198.51.200.2), the output could still match. So change to grep "bytes from $from" instead. Fixes: 40f98b9af943 ("selftests: add a selftest for directed broadcast forwarding") Signed-off-by: Xin Long <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-06-03net: ethernet: mediatek: Use NET_IP_ALIGN to judge if HW RX_2BYTE_OFFSET is ↵Sean Wang1-1/+2
enabled Should only enable HW RX_2BYTE_OFFSET function in the case NET_IP_ALIGN equals to 2. Signed-off-by: Mark Lee <[email protected]> Signed-off-by: Sean Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-06-03net: ethernet: mediatek: Use hw_feature to judge if HWLRO is supportedSean Wang1-6/+6
Should hw_feature as hardware capability flags to check if hardware LRO got support. Signed-off-by: Mark Lee <[email protected]> Signed-off-by: Sean Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-06-03Merge tag 'arc-5.2-rc4' of ↵Linus Torvalds5-20/+64
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fixes from Vineet Gupta: - Fix for userspace trying to access kernel vaddr space - HSDK platform DT updates - Cleanup some build warnings * tag 'arc-5.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARC: [plat-hsdk] Get rid of inappropriate PHY settings ARC: [plat-hsdk]: Add support of Vivante GPU ARC: [plat-hsdk]: enable creg-gpio controller ARC: [plat-hsdk]: Add missing FIFO size entry in GMAC node ARC: [plat-hsdk]: Add missing multicast filter bins number to GMAC node ARC: mm: SIGSEGV userspace trying to access kernel virtual memory ARC: fix build warnings
2019-06-03net: ethernet: ti: cpsw_ethtool: fix ethtool ring param setIvan Khoronzhuk1-1/+1
Fix ability to set RX descriptor number, the reason - initially "tx_max_pending" was set incorrectly, but the issue appears after adding sanity check, so fix is for "sanity" patch. Fixes: 37e2d99b59c476 ("ethtool: Ensure new ring parameters are within bounds during SRINGPARAM") Signed-off-by: Ivan Khoronzhuk <[email protected]> Reviewed-by: Grygorii Strashko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-06-03rcu: locking and unlocking need to always be at least barriersLinus Torvalds1-4/+2
Herbert Xu pointed out that commit bb73c52bad36 ("rcu: Don't disable preemption for Tiny and Tree RCU readers") was incorrect in making the preempt_disable/enable() be conditional on CONFIG_PREEMPT_COUNT. If CONFIG_PREEMPT_COUNT isn't enabled, the preemption enable/disable is a no-op, but still is a compiler barrier. And RCU locking still _needs_ that compiler barrier. It is simply fundamentally not true that RCU locking would be a complete no-op: we still need to guarantee (for example) that things that can trap and cause preemption cannot migrate into the RCU locked region. The way we do that is by making it a barrier. See for example commit 386afc91144b ("spinlocks and preemption points need to be at least compiler barriers") from back in 2013 that had similar issues with spinlocks that become no-ops on UP: they must still constrain the compiler from moving other operations into the critical region. Now, it is true that a lot of RCU operations already use READ_ONCE() and WRITE_ONCE() (which in practice likely would never be re-ordered wrt anything remotely interesting), but it is also true that that is not globally the case, and that it's not even necessarily always possible (ie bitfields etc). Reported-by: Herbert Xu <[email protected]> Fixes: bb73c52bad36 ("rcu: Don't disable preemption for Tiny and Tree RCU readers") Cc: [email protected] Cc: Boqun Feng <[email protected]> Cc: Paul E. McKenney <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-06-03Merge tag 'nds32-for-linux-5.2-rc3' of ↵Linus Torvalds26-66/+464
git://git.kernel.org/pub/scm/linux/kernel/git/greentime/linux Pull nds32 fixes from Greentime Hu: - fix warning for math-emu - fix nds32 fpu exception handling - fix nds32 fpu emulation implementation * tag 'nds32-for-linux-5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/greentime/linux: nds32: add new emulations for floating point instruction nds32: Avoid IEX status being incorrectly modified math-emu: Use statement expressions to fix Wshift-count-overflow warning
2019-06-03Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds3-2/+8
Pull sparc fixes from David Miller: "Three bug fixes, and TLB flushing one is of particular brown paper bag quality..." * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc: perf: fix updated event period in response to PERF_EVENT_IOC_PERIOD mdesc: fix a missing-check bug in get_vdev_port_node_info() sparc64: Fix regression in non-hypervisor TLB flush xcall
2019-06-03Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds7-48/+77
Pull virtio fixes from Michael Tsirkin: "Several fixes, some of them for CVEs" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: vhost: scsi: add weight support vhost: vsock: add weight support vhost_net: fix possible infinite loop vhost: introduce vhost_exceeds_weight() virtio: Fix indentation of VIRTIO_MMIO virtio: add unlikely() to WARN_ON_ONCE()
2019-06-03ASoC: SOF: fix DSP oops definitions in FW ABIKai Vehmanen6-22/+58
The definitions for DSP oops structures were not aligned correctly to current FW ABI version 3.6.0, leading to invalid data being printed out to debug logs. Fix the structs and update related platform code accordingly. Signed-off-by: Kai Vehmanen <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-03ASoC: hda: fix unbalanced codec dev refcount for HDA_DEV_ASOCRanjani Sridharan1-1/+8
HDA_DEV_ASOC type codec device refcounts are managed differently from HDA_DEV_LEGACY devices. The refcount is released explicitly in snd_hdac_ext_bus_device_remove() for ASOC type devices. So, remove the put_device() call in snd_hda_codec_dev_free() for such devices to make the refcount balanced. This will prevent the NULL pointer exception when the codec driver is released after the card is freed. Signed-off-by: Ranjani Sridharan <[email protected]> Reviewed-by: Takashi Iwai <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-03ASoC: SOF: ipc: replace fw ready bitfield with explicit bit orderingSlawomir Blauciak2-14/+17
Previously the structure used bitfields, which do not guarantee bit ordering. This change makes sure the order is clearly defined. It also renames and repurposes the field for general use. Signed-off-by: Slawomir Blauciak <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-03ASoC: SOF: bump to ABI 3.6Pierre-Louis Bossart1-1/+1
We had a couple of misses with ABI changes, e.g. for Xtensa oops information and the integration of sound trigger, before we set-up a formal process to track evolutions. With this patch, the SOF kernel patches are officially aligned with the firmware 3.6 level. Changing this level has no impact on existing users and is fully backwards-compatible. Signed-off-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-03ASoC: SOF: soundwire: add initial soundwire supportPan Xiuli2-1/+2
Add soundwire dai type and update ABI version. Signed-off-by: Pan Xiuli <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-03ASoC: SOF: uapi: mirror firmware changesPierre-Louis Bossart1-0/+2
We missed these two definitions for GDB support and component notifications, they are defined for the SOF firmware. Since they are not used by the kernel so far, we can still add them without any ABI change. Signed-off-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-03ASoC: Intel: Baytrail: add quirk for Aegex 10 (RU2) tabletKovács Tamás2-0/+29
This tablet has an incorrect acpi identifier just like Thinkpad10 tablet, which is why it is trying to load the RT5640 driver instead of the RT5762 driver. The RT5640 driver, on the other hand, checks the hardware ID, so no driver are loaded during boot. This fix resolves to load the RT5672 driver on this tablet during boot. It also provides the correct IO configuration, like the jack detect mode 3, for 1.8V pullup. I would like to thank Pierre-Louis Bossart for helping with this patch. Signed-off-by: Kovács Tamás <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-03xfs: inode btree scrubber should calculate im_boffset correctlyDarrick J. Wong1-1/+2
The im_boffset field is in units of bytes, whereas XFS_INO_OFFSET returns a value in units of inodes. Convert the units so that scrub on a 64k-block filesystem works correctly. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Brian Foster <[email protected]>
2019-06-03mmc: sdhci_am654: Fix SLOTTYPE writeFaiz Abbas1-1/+1
In the call to regmap_update_bits() for SLOTTYPE, the mask and value fields are exchanged. Fix this. Signed-off-by: Faiz Abbas <[email protected]> Fixes: 41fd4caeb00b ("mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver") Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]>
2019-06-03soc: imx: Add SCU SoC info driver supportAnson Huang3-0/+154
Add i.MX SCU SoC info driver to support i.MX8QXP SoC, introduce driver dependency into Kconfig as CONFIG_IMX_SCU must be selected to support i.MX SCU SoC driver, also need to use platform driver model to make sure IMX_SCU driver is probed before i.MX SCU SoC driver. With this patch, SoC info can be read from sysfs: i.mx8qxp-mek# cat /sys/devices/soc0/family Freescale i.MX i.mx8qxp-mek# cat /sys/devices/soc0/soc_id 0x2 i.mx8qxp-mek# cat /sys/devices/soc0/machine Freescale i.MX8QXP MEK i.mx8qxp-mek# cat /sys/devices/soc0/revision 1.1 Signed-off-by: Anson Huang <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Reviewed-by: Dong Aisheng <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2019-06-03usb: typec: ucsi: ccg: fix memory leak in do_flashGustavo A. R. Silva1-2/+4
In case memory resources for *fw* were successfully allocated, release them before return. Addresses-Coverity-ID: 1445499 ("Resource leak") Fixes: 5c9ae5a87573 ("usb: typec: ucsi: ccg: add firmware flashing support") Signed-off-by: Gustavo A. R. Silva <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-06-03habanalabs: Fix virtual address access via debugfs for 2MB pagesTomer Tayar1-1/+4
The debugfs interface for accessing DRAM virtual addresses currently uses the 12 LSBs of a virtual address as an offset. However, it should use the 20 LSBs in case the device MMU page size is 2MB instead of 4KB. This patch fixes the offset calculation to be based on the page size. Signed-off-by: Tomer Tayar <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2019-06-03drm/komeda: Constify the usage of komeda_component/pipeline/dev_funcsjames qian wang (Arm Technology China)7-18/+18
Depends on: - https://patchwork.freedesktop.org/series/58976/ - https://patchwork.freedesktop.org/series/59855/ Reported-by: Emil Velikov <[email protected]> Signed-off-by: James Qian Wang (Arm Technology China) <[email protected]> Signed-off-by: Liviu Dudau <[email protected]>
2019-06-03x86/power: Fix 'nosmt' vs hibernation triple fault during resumeJiri Kosina5-2/+58
As explained in 0cc3cd21657b ("cpu/hotplug: Boot HT siblings at least once") we always, no matter what, have to bring up x86 HT siblings during boot at least once in order to avoid first MCE bringing the system to its knees. That means that whenever 'nosmt' is supplied on the kernel command-line, all the HT siblings are as a result sitting in mwait or cpudile after going through the online-offline cycle at least once. This causes a serious issue though when a kernel, which saw 'nosmt' on its commandline, is going to perform resume from hibernation: if the resume from the hibernated image is successful, cr3 is flipped in order to point to the address space of the kernel that is being resumed, which in turn means that all the HT siblings are all of a sudden mwaiting on address which is no longer valid. That results in triple fault shortly after cr3 is switched, and machine reboots. Fix this by always waking up all the SMT siblings before initiating the 'restore from hibernation' process; this guarantees that all the HT siblings will be properly carried over to the resumed kernel waiting in resume_play_dead(), and acted upon accordingly afterwards, based on the target kernel configuration. Symmetricaly, the resumed kernel has to push the SMT siblings to mwait again in case it has SMT disabled; this means it has to online all the siblings when resuming (so that they come out of hlt) and offline them again to let them reach mwait. Cc: 4.19+ <[email protected]> # v4.19+ Debugged-by: Thomas Gleixner <[email protected]> Fixes: 0cc3cd21657b ("cpu/hotplug: Boot HT siblings at least once") Signed-off-by: Jiri Kosina <[email protected]> Acked-by: Pavel Machek <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Reviewed-by: Josh Poimboeuf <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-06-03mm/vmalloc: Avoid rare case of flushing TLB with weird argumentsRick Edgecombe1-1/+3
In a rare case, flush_tlb_kernel_range() could be called with a start higher than the end. In vm_remove_mappings(), in case page_address() returns 0 for all pages (for example they were all in highmem), _vm_unmap_aliases() will be called with start = ULONG_MAX, end = 0 and flush = 1. If at the same time, the vmalloc purge operation is triggered by something else while the current operation is between remove_vm_area() and _vm_unmap_aliases(), then the vm mapping just removed will be already purged. In this case the call of vm_unmap_aliases() may not find any other mappings to flush and so end up flushing start = ULONG_MAX, end = 0. So only set flush = true if we find something in the direct mapping that we need to flush, and this way this can't happen. Signed-off-by: Rick Edgecombe <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David S. Miller <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Meelis Roos <[email protected]> Cc: Nadav Amit <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Thomas Gleixner <[email protected]> Fixes: 868b104d7379 ("mm/vmalloc: Add flag for freeing of special permsissions") Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-06-03mm/vmalloc: Fix calculation of direct map addr rangeRick Edgecombe1-5/+5
The calculation of the direct map address range to flush was wrong. This could cause the RO direct map alias to not get flushed. Today this shouldn't be a problem because this flush is only needed on x86 right now and the spurious fault handler will fix cached RO->RW translations. In the future though, it could cause the permissions to remain RO in the TLB for the direct map alias, and then the page would return from the page allocator to some other component as RO and cause a crash. So fix fix the address range calculation so the flush will include the direct map range. Signed-off-by: Rick Edgecombe <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David S. Miller <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Meelis Roos <[email protected]> Cc: Nadav Amit <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Fixes: 868b104d7379 ("mm/vmalloc: Add flag for freeing of special permsissions") Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-06-03PM: sleep: Add kerneldoc comments to some functionsRafael J. Wysocki2-0/+37
Add kerneldoc comments to pm_suspend_via_firmware(), pm_resume_via_firmware() and pm_suspend_via_s2idle() to explain what they do. Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-06-03drm/i915/gvt: save RING_HEAD into vreg when vgpu switched outXiaolin Zhang3-0/+28
Save RING_HEAD into vgpu reg when vgpu switched out and report it's value back to guest. v6: addressed comment for ring head wrap count support. (Zhenyu) v5: ring head wrap count support. v4: updated HEAD/TAIL with guest value, not host value. (Yan Zhao) v3: save RING HEAD/TAIL vgpu reg in save_ring_hw_state. (Zhenyu Wang) v2: save RING_TAIL as well during vgpu mmio switch to meet ring_is_idle condition. (Fred Gao) v1: based on input from Weinan. (Weinan Li) [zhenyuw: Include this fix for possible future guest kernel that would utilize RING_HEAD for hangcheck.] Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Xiaolin Zhang <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]>
2019-06-02sparc: perf: fix updated event period in response to PERF_EVENT_IOC_PERIODYoung Xiao1-0/+4
The PERF_EVENT_IOC_PERIOD ioctl command can be used to change the sample period of a running perf_event. Consequently, when calculating the next event period, the new period will only be considered after the previous one has overflowed. This patch changes the calculation of the remaining event ticks so that they are offset if the period has changed. See commit 3581fe0ef37c ("ARM: 7556/1: perf: fix updated event period in response to PERF_EVENT_IOC_PERIOD") for details. Signed-off-by: Young Xiao <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-06-02mdesc: fix a missing-check bug in get_vdev_port_node_info()Gen Zhang1-0/+2
In get_vdev_port_node_info(), 'node_info->vdev_port.name' is allcoated by kstrdup_const(), and it returns NULL when fails. So 'node_info->vdev_port.name' should be checked. Signed-off-by: Gen Zhang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-06-03drm/i915/gvt: add F_CMD_ACCESS flag for wa regsWeinan Li1-6/+7
Instead of updating by MMIO write, all of the wa regs are initialized by wa_ctx. From host side, it should make this behavior as expected, add 'F_CMD_ACCESS' flag to these regs and allow access by commands. [ 123.557608] gvt: vgpu 2: srm access to non-render register (b11c) [ 123.563728] gvt: vgpu 2: MI_STORE_REGISTER_MEM handler error [ 123.569409] gvt: vgpu 2: cmd parser error [ 123.573424] 0x0 [ 123.573425] 0x24 [ 123.578686] gvt: vgpu 2: scan workload error [ 123.582958] GVT Internal error for the guest [ 123.587317] Now vgpu 2 will enter failsafe mode. [ 123.591938] gvt: vgpu 2: failed to submit desc 0 [ 123.596557] gvt: vgpu 2: fail submit workload on ring 0 [ 123.601786] gvt: vgpu 2: fail to emulate MMIO write 00002230 len 4 Acked-by: Yan Zhao <[email protected]> Signed-off-by: Weinan Li <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.