aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-01-13mm: memcg/slab: fix percpu slab vmstats flushingRoman Gushchin2-31/+11
Currently slab percpu vmstats are flushed twice: during the memcg offlining and just before freeing the memcg structure. Each time percpu counters are summed, added to the atomic counterparts and propagated up by the cgroup tree. The second flushing is required due to how recursive vmstats are implemented: counters are batched in percpu variables on a local level, and once a percpu value is crossing some predefined threshold, it spills over to atomic values on the local and each ascendant levels. It means that without flushing some numbers cached in percpu variables will be dropped on floor each time a cgroup is destroyed. And with uptime the error on upper levels might become noticeable. The first flushing aims to make counters on ancestor levels more precise. Dying cgroups may resume in the dying state for a long time. After kmem_cache reparenting which is performed during the offlining slab counters of the dying cgroup don't have any chances to be updated, because any slab operations will be performed on the parent level. It means that the inaccuracy caused by percpu batching will not decrease up to the final destruction of the cgroup. By the original idea flushing slab counters during the offlining should minimize the visible inaccuracy of slab counters on the parent level. The problem is that percpu counters are not zeroed after the first flushing. So every cached percpu value is summed twice. It creates a small error (up to 32 pages per cpu, but usually less) which accumulates on parent cgroup level. After creating and destroying of thousands of child cgroups, slab counter on parent level can be way off the real value. For now, let's just stop flushing slab counters on memcg offlining. It can't be done correctly without scheduling a work on each cpu: reading and zeroing it during css offlining can race with an asynchronous update, which doesn't expect values to be changed underneath. With this change, slab counters on parent level will become eventually consistent. Once all dying children are gone, values are correct. And if not, the error is capped by 32 * NR_CPUS pages per dying cgroup. It's not perfect, as slab are reparented, so any updates after the reparenting will happen on the parent level. It means that if a slab page was allocated, a counter on child level was bumped, then the page was reparented and freed, the annihilation of positive and negative counter values will not happen until the child cgroup is released. It makes slab counters different from others, and it might want us to implement flushing in a correct form again. But it's also a question of performance: scheduling a work on each cpu isn't free, and it's an open question if the benefit of having more accurate counters is worth it. We might also consider flushing all counters on offlining, not only slab counters. So let's fix the main problem now: make the slab counters eventually consistent, so at least the error won't grow with uptime (or more precisely the number of created and destroyed cgroups). And think about the accuracy of counters separately. Link: http://lkml.kernel.org/r/[email protected] Fixes: bee07b33db78 ("mm: memcontrol: flush percpu slab vmstats on kmem offlining") Signed-off-by: Roman Gushchin <[email protected]> Acked-by: Johannes Weiner <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-01-13mm/shmem.c: thp, shmem: fix conflict of above-47bit hint address and PMD ↵Kirill A. Shutemov1-3/+4
alignment Shmem/tmpfs tries to provide THP-friendly mappings if huge pages are enabled. But it doesn't work well with above-47bit hint address. Normally, the kernel doesn't create userspace mappings above 47-bit, even if the machine allows this (such as with 5-level paging on x86-64). Not all user space is ready to handle wide addresses. It's known that at least some JIT compilers use higher bits in pointers to encode their information. Userspace can ask for allocation from full address space by specifying hint address (with or without MAP_FIXED) above 47-bits. If the application doesn't need a particular address, but wants to allocate from whole address space it can specify -1 as a hint address. Unfortunately, this trick breaks THP alignment in shmem/tmp: shmem_get_unmapped_area() would not try to allocate PMD-aligned area if *any* hint address specified. This can be fixed by requesting the aligned area if the we failed to allocated at user-specified hint address. The request with inflated length will also take the user-specified hint address. This way we will not lose an allocation request from the full address space. [[email protected]: fold in a fixup] Link: http://lkml.kernel.org/r/20191223231309.t6bh5hkbmokihpfu@box Link: http://lkml.kernel.org/r/[email protected] Fixes: b569bab78d8d ("x86/mm: Prepare to expose larger address space to userspace") Signed-off-by: Kirill A. Shutemov <[email protected]> Cc: "Willhalm, Thomas" <[email protected]> Cc: Dan Williams <[email protected]> Cc: "Bruggeman, Otto G" <[email protected]> Cc: "Aneesh Kumar K . V" <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-01-13mm/huge_memory.c: thp: fix conflict of above-47bit hint address and PMD ↵Kirill A. Shutemov1-14/+24
alignment Patch series "Fix two above-47bit hint address vs. THP bugs". The two get_unmapped_area() implementations have to be fixed to provide THP-friendly mappings if above-47bit hint address is specified. This patch (of 2): Filesystems use thp_get_unmapped_area() to provide THP-friendly mappings. For DAX in particular. Normally, the kernel doesn't create userspace mappings above 47-bit, even if the machine allows this (such as with 5-level paging on x86-64). Not all user space is ready to handle wide addresses. It's known that at least some JIT compilers use higher bits in pointers to encode their information. Userspace can ask for allocation from full address space by specifying hint address (with or without MAP_FIXED) above 47-bits. If the application doesn't need a particular address, but wants to allocate from whole address space it can specify -1 as a hint address. Unfortunately, this trick breaks thp_get_unmapped_area(): the function would not try to allocate PMD-aligned area if *any* hint address specified. Modify the routine to handle it correctly: - Try to allocate the space at the specified hint address with length padding required for PMD alignment. - If failed, retry without length padding (but with the same hint address); - If the returned address matches the hint address return it. - Otherwise, align the address as required for THP and return. The user specified hint address is passed down to get_unmapped_area() so above-47bit hint address will be taken into account without breaking alignment requirements. Link: http://lkml.kernel.org/r/[email protected] Fixes: b569bab78d8d ("x86/mm: Prepare to expose larger address space to userspace") Signed-off-by: Kirill A. Shutemov <[email protected]> Reported-by: Thomas Willhalm <[email protected]> Tested-by: Dan Williams <[email protected]> Cc: "Aneesh Kumar K . V" <[email protected]> Cc: "Bruggeman, Otto G" <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-01-13mm/memory_hotplug: don't free usage map when removing a re-added early sectionDavid Hildenbrand1-1/+8
When we remove an early section, we don't free the usage map, as the usage maps of other sections are placed into the same page. Once the section is removed, it is no longer an early section (especially, the memmap is freed). When we re-add that section, the usage map is reused, however, it is no longer an early section. When removing that section again, we try to kfree() a usage map that was allocated during early boot - bad. Let's check against PageReserved() to see if we are dealing with an usage map that was allocated during boot. We could also check against !(PageSlab(usage_page) || PageCompound(usage_page)), but PageReserved() is cleaner. Can be triggered using memtrace under ppc64/powernv: $ mount -t debugfs none /sys/kernel/debug/ $ echo 0x20000000 > /sys/kernel/debug/powerpc/memtrace/enable $ echo 0x20000000 > /sys/kernel/debug/powerpc/memtrace/enable ------------[ cut here ]------------ kernel BUG at mm/slub.c:3969! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=3D64K MMU=3DHash SMP NR_CPUS=3D2048 NUMA PowerNV Modules linked in: CPU: 0 PID: 154 Comm: sh Not tainted 5.5.0-rc2-next-20191216-00005-g0be1dba7b7c0 #61 NIP kfree+0x338/0x3b0 LR section_deactivate+0x138/0x200 Call Trace: section_deactivate+0x138/0x200 __remove_pages+0x114/0x150 arch_remove_memory+0x3c/0x160 try_remove_memory+0x114/0x1a0 __remove_memory+0x20/0x40 memtrace_enable_set+0x254/0x850 simple_attr_write+0x138/0x160 full_proxy_write+0x8c/0x110 __vfs_write+0x38/0x70 vfs_write+0x11c/0x2a0 ksys_write+0x84/0x140 system_call+0x5c/0x68 ---[ end trace 4b053cbd84e0db62 ]--- The first invocation will offline+remove memory blocks. The second invocation will first add+online them again, in order to offline+remove them again (usually we are lucky and the exact same memory blocks will get "reallocated"). Tested on powernv with boot memory: The usage map will not get freed. Tested on x86-64 with DIMMs: The usage map will get freed. Using Dynamic Memory under a Power DLAPR can trigger it easily. Triggering removal (I assume after previously removed+re-added) of memory from the HMC GUI can crash the kernel with the same call trace and is fixed by this patch. Link: http://lkml.kernel.org/r/[email protected] Fixes: 326e1b8f83a4 ("mm/sparsemem: introduce a SECTION_IS_EARLY flag") Signed-off-by: David Hildenbrand <[email protected]> Tested-by: Pingfan Liu <[email protected]> Cc: Dan Williams <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-01-13mm, thp: tweak reclaim/compaction effort of local-only and all-node allocationsVlastimil Babka2-22/+12
THP page faults now attempt a __GFP_THISNODE allocation first, which should only compact existing free memory, followed by another attempt that can allocate from any node using reclaim/compaction effort specified by global defrag setting and madvise. This patch makes the following changes to the scheme: - Before the patch, the first allocation relies on a check for pageblock order and __GFP_IO to prevent excessive reclaim. This however affects also the second attempt, which is not limited to single node. Instead of that, reuse the existing check for costly order __GFP_NORETRY allocations, and make sure the first THP attempt uses __GFP_NORETRY. As a side-effect, all costly order __GFP_NORETRY allocations will bail out if compaction needs reclaim, while previously they only bailed out when compaction was deferred due to previous failures. This should be still acceptable within the __GFP_NORETRY semantics. - Before the patch, the second allocation attempt (on all nodes) was passing __GFP_NORETRY. This is redundant as the check for pageblock order (discussed above) was stronger. It's also contrary to madvise(MADV_HUGEPAGE) which means some effort to allocate THP is requested. After this patch, the second attempt doesn't pass __GFP_THISNODE nor __GFP_NORETRY. To sum up, THP page faults now try the following attempts: 1. local node only THP allocation with no reclaim, just compaction. 2. for madvised VMA's or when synchronous compaction is enabled always - THP allocation from any node with effort determined by global defrag setting and VMA madvise 3. fallback to base pages on any node Link: http://lkml.kernel.org/r/[email protected] Fixes: b39d0ee2632d ("mm, page_alloc: avoid expensive reclaim when compaction may not succeed") Signed-off-by: Vlastimil Babka <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Mel Gorman <[email protected]> Cc: "Kirill A. Shutemov" <[email protected]> Cc: David Rientjes <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-01-13btrfs: relocation: fix reloc_root lifespan and accessQu Wenruo1-5/+46
[BUG] There are several different KASAN reports for balance + snapshot workloads. Involved call paths include: should_ignore_root+0x54/0xb0 [btrfs] build_backref_tree+0x11af/0x2280 [btrfs] relocate_tree_blocks+0x391/0xb80 [btrfs] relocate_block_group+0x3e5/0xa00 [btrfs] btrfs_relocate_block_group+0x240/0x4d0 [btrfs] btrfs_relocate_chunk+0x53/0xf0 [btrfs] btrfs_balance+0xc91/0x1840 [btrfs] btrfs_ioctl_balance+0x416/0x4e0 [btrfs] btrfs_ioctl+0x8af/0x3e60 [btrfs] do_vfs_ioctl+0x831/0xb10 create_reloc_root+0x9f/0x460 [btrfs] btrfs_reloc_post_snapshot+0xff/0x6c0 [btrfs] create_pending_snapshot+0xa9b/0x15f0 [btrfs] create_pending_snapshots+0x111/0x140 [btrfs] btrfs_commit_transaction+0x7a6/0x1360 [btrfs] btrfs_mksubvol+0x915/0x960 [btrfs] btrfs_ioctl_snap_create_transid+0x1d5/0x1e0 [btrfs] btrfs_ioctl_snap_create_v2+0x1d3/0x270 [btrfs] btrfs_ioctl+0x241b/0x3e60 [btrfs] do_vfs_ioctl+0x831/0xb10 btrfs_reloc_pre_snapshot+0x85/0xc0 [btrfs] create_pending_snapshot+0x209/0x15f0 [btrfs] create_pending_snapshots+0x111/0x140 [btrfs] btrfs_commit_transaction+0x7a6/0x1360 [btrfs] btrfs_mksubvol+0x915/0x960 [btrfs] btrfs_ioctl_snap_create_transid+0x1d5/0x1e0 [btrfs] btrfs_ioctl_snap_create_v2+0x1d3/0x270 [btrfs] btrfs_ioctl+0x241b/0x3e60 [btrfs] do_vfs_ioctl+0x831/0xb10 [CAUSE] All these call sites are only relying on root->reloc_root, which can undergo btrfs_drop_snapshot(), and since we don't have real refcount based protection to reloc roots, we can reach already dropped reloc root, triggering KASAN. [FIX] To avoid such access to unstable root->reloc_root, we should check BTRFS_ROOT_DEAD_RELOC_TREE bit first. This patch introduces wrappers that provide the correct way to check the bit with memory barriers protection. Most callers don't distinguish merged reloc tree and no reloc tree. The only exception is should_ignore_root(), as merged reloc tree can be ignored, while no reloc tree shouldn't. [CRITICAL SECTION ANALYSIS] Although test_bit()/set_bit()/clear_bit() doesn't imply a barrier, the DEAD_RELOC_TREE bit has extra help from transaction as a higher level barrier, the lifespan of root::reloc_root and DEAD_RELOC_TREE bit are: NULL: reloc_root is NULL PTR: reloc_root is not NULL 0: DEAD_RELOC_ROOT bit not set DEAD: DEAD_RELOC_ROOT bit set (NULL, 0) Initial state __ | /\ Section A btrfs_init_reloc_root() \/ | __ (PTR, 0) reloc_root initialized /\ | | btrfs_update_reloc_root() | Section B | | (PTR, DEAD) reloc_root has been merged \/ | __ === btrfs_commit_transaction() ==================== | /\ clean_dirty_subvols() | | | Section C (NULL, DEAD) reloc_root cleanup starts \/ | __ btrfs_drop_snapshot() /\ | | Section D (NULL, 0) Back to initial state \/ Every have_reloc_root() or test_bit(DEAD_RELOC_ROOT) caller holds transaction handle, so none of such caller can cross transaction boundary. In Section A, every caller just found no DEAD bit, and grab reloc_root. In the cross section A-B, caller may get no DEAD bit, but since reloc_root is still completely valid thus accessing reloc_root is completely safe. No test_bit() caller can cross the boundary of Section B and Section C. In Section C, every caller found the DEAD bit, so no one will access reloc_root. In the cross section C-D, either caller gets the DEAD bit set, avoiding access reloc_root no matter if it's safe or not. Or caller get the DEAD bit cleared, then access reloc_root, which is already NULL, nothing will be wrong. The memory write barriers are between the reloc_root updates and bit set/clear, the pairing read side is before test_bit. Reported-by: Zygo Blaxell <[email protected]> Fixes: d2311e698578 ("btrfs: relocation: Delay reloc tree deletion after merge_reloc_roots") CC: [email protected] # 5.4+ Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> [ barriers ] Signed-off-by: David Sterba <[email protected]>
2020-01-13iio: imu: adis: use new `delay` structure for SPI transfer delaysAlexandru Ardelean1-9/+18
In a recent change to the SPI subsystem [1], a new `delay` struct was added to replace the `delay_usecs`. This change replaces the current `delay_usecs` with `delay` for this driver. The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure that both `delay_usecs` & `delay` are used (in this order to preserve backwards compatibility). [1] commit bebcfd272df6485 ("spi: introduce `delay` field for `spi_transfer` + spi_transfer_delay_exec()") Signed-off-by: Alexandru Ardelean <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2020-01-13iio: adc: stm32-dfsdm: adapt sampling rate to oversampling ratioOlivier Moysan1-13/+19
Update sampling rate when oversampling ratio is changed through the IIO ABI. Signed-off-by: Olivier Moysan <[email protected]> Acked-by: Fabrice Gasnier <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2020-01-13iio: adc: stm32-dfsdm: fix single conversionOlivier Moysan1-0/+2
Apply data formatting to single conversion, as this is already done in continuous and trigger modes. Fixes: 102afde62937 ("iio: adc: stm32-dfsdm: manage data resolution in trigger mode") Signed-off-by: Olivier Moysan <[email protected]> Cc: <[email protected]> Acked-by: Fabrice Gasnier <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2020-01-13iio: st_sensors: Make use of device propertiesAndy Shevchenko10-61/+20
Device property API allows to gather device resources from different sources, such as ACPI. Convert the drivers to unleash the power of device property API. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2020-01-13iio: st_sensors: Drop redundant parameter from st_sensors_of_name_probe()Andy Shevchenko11-88/+25
Since we have access to the struct device_driver and thus to the ID table, there is no need to supply special parameters to st_sensors_of_name_probe(). Besides that we have a common API to get driver match data, there is no need to do matching separately for OF and ACPI. Taking into consideration above, simplify the ST sensors code. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2020-01-13iio: st_gyro: Correct data for LSM9DS0 gyroAndy Shevchenko1-1/+74
The commit 41c128cb25ce ("iio: st_gyro: Add lsm9ds0-gyro support") assumes that gyro in LSM9DS0 is the same as others with 0xd4 WAI ID, but datasheet tells slight different story, i.e. the first scale factor for the chip is 245 dps, and not 250 dps. Correct this by introducing a separate settings for LSM9DS0. Fixes: 41c128cb25ce ("iio: st_gyro: Add lsm9ds0-gyro support") Depends-on: 45a4e4220bf4 ("iio: gyro: st_gyro: fix L3GD20H support") Cc: Leonard Crestez <[email protected]> Cc: Lorenzo Bianconi <[email protected]> Cc: <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2020-01-13iio: imu: st_lsm6dsx: check return value from st_lsm6dsx_sensor_set_enableLorenzo Bianconi1-2/+5
Add missing return value check in st_lsm6dsx_read_oneshot disabling the sensor. The issue is reported by coverity with the following error: Unchecked return value: If the function returns an error value, the error value may be mistaken for a normal value. Addresses-Coverity-ID: 1446733 ("Unchecked return value") Fixes: b5969abfa8b8 ("iio: imu: st_lsm6dsx: add motion events") Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver") Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2020-01-13Documentation/ABI: Add missed attribute for mlxreg-io sysfs interfacesVadim Pasternak1-0/+9
Add missed "cpld4_version" attribute. Fixes: 52675da1d087 ("Documentation/ABI: Add new attribute for mlxreg-io sysfs interfaces") Signed-off-by: Vadim Pasternak <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2020-01-13Documentation/ABI: Fix documentation inconsistency for mlxreg-io sysfs ↵Vadim Pasternak1-2/+2
interfaces Fix attribute name from "jtag_enable", which described twice to "cpld3_version", which is expected to be instead of second appearance of "jtag_enable". Fixes: 2752e34442b5 ("Documentation/ABI: Add new attribute for mlxreg-io sysfs interfaces") Signed-off-by: Vadim Pasternak <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2020-01-13netfilter: arp_tables: init netns pointer in xt_tgdtor_param structFlorian Westphal1-9/+10
An earlier commit (1b789577f655060d98d20e, "netfilter: arp_tables: init netns pointer in xt_tgchk_param struct") fixed missing net initialization for arptables, but turns out it was incomplete. We can get a very similar struct net NULL deref during error unwinding: general protection fault: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:xt_rateest_put+0xa1/0x440 net/netfilter/xt_RATEEST.c:77 xt_rateest_tg_destroy+0x72/0xa0 net/netfilter/xt_RATEEST.c:175 cleanup_entry net/ipv4/netfilter/arp_tables.c:509 [inline] translate_table+0x11f4/0x1d80 net/ipv4/netfilter/arp_tables.c:587 do_replace net/ipv4/netfilter/arp_tables.c:981 [inline] do_arpt_set_ctl+0x317/0x650 net/ipv4/netfilter/arp_tables.c:1461 Also init the netns pointer in xt_tgdtor_param struct. Fixes: add67461240c1d ("netfilter: add struct net * to target parameters") Reported-by: [email protected] Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-01-13Merge tag 'sunxi-clk-fixes-for-5.5' of ↵Stephen Boyd5-37/+12
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into clk-fixes Pull Allwinner clk fixes from Maxime Ripard: Our usual set of fixes for Allwinner, to fix the number of reported clocks on the v3s, fixing the external clock on the R40, and some fixes for the AR100 co-processor clocks. * tag 'sunxi-clk-fixes-for-5.5' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: clk: sunxi-ng: h6-r: Fix AR100/R_APB2 parent order clk: sunxi-ng: h6-r: Simplify R_APB1 clock definition clk: sunxi-ng: sun8i-r: Fix divider on APB0 clock clk: sunxi-ng: r40: Allow setting parent rate for external clock outputs clk: sunxi-ng: v3s: Fix incorrect number of hw_clks.
2020-01-13netfilter: fix a use-after-free in mtype_destroy()Cong Wang1-1/+1
map->members is freed by ip_set_free() right before using it in mtype_ext_cleanup() again. So we just have to move it down. Reported-by: [email protected] Fixes: 40cd63bf33b2 ("netfilter: ipset: Support extensions which need a per data destroy function") Acked-by: Jozsef Kadlecsik <[email protected]> Signed-off-by: Cong Wang <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-01-13irqchip/ingenic: Get rid of the legacy IRQ domainPaul Cercueil1-4/+2
Get rid of the legacy IRQ domain and hardcoded IRQ base, since all the Ingenic drivers and platform code have been updated to use devicetree. This also fixes the kernel being flooded with messages like: irq: interrupt-controller@10001000 didn't like hwirq-0x0 to VIRQ8 mapping (rc=-19) Fixes: 8bc7464b5140 ("irqchip: ingenic: Alloc generic chips from IRQ domain"). Signed-off-by: Paul Cercueil <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: H. Nikolaus Schaller <[email protected]> Tested-by: 周琰杰 (Zhou Yanjie) <[email protected]> Acked-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-13USB: serial: option: Add support for Quectel RM500QKristian Evensen1-0/+4
RM500Q is a 5G module from Quectel, supporting both standalone and non-standalone modes. Unlike other recent Quectel modems, it is possible to identify the diagnostic interface (bInterfaceProtocol is unique). Thus, there is no need to check for the number of endpoints or reserve interfaces. The interface number is still dynamic though, so matching on interface number is not possible and two entries have to be added to the table. Output from usb-devices with all interfaces enabled (order is diag, nmea, at_port, modem, rmnet and adb): Bus 004 Device 007: ID 2c7c:0800 Quectel Wireless Solutions Co., Ltd. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2c7c Quectel Wireless Solutions Co., Ltd. idProduct 0x0800 bcdDevice 4.14 iManufacturer 1 Quectel iProduct 2 LTE-A Module iSerial 3 40046d60 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 328 bNumInterfaces 6 bConfigurationValue 1 iConfiguration 4 DIAG_SER_RMNET bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 224mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 5 CDEV Serial Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0f EP 15 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 2 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 66 bInterfaceProtocol 1 iInterface 6 ADB Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x89 EP 9 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 42 bNumDeviceCaps 3 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000006 Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000f Device can operate at Low Speed (1Mbps) Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 1 micro seconds bU2DevExitLat 500 micro seconds ** UNRECOGNIZED: 14 10 0a 00 01 00 00 00 00 11 00 00 30 40 0a 00 b0 40 0a 00 Device Status: 0x0000 (Bus Powered) Signed-off-by: Kristian Evensen <[email protected]> Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2020-01-13ASoC: msm8916-wcd-digital: Reset RX interpolation path after useStephan Gerhold1-0/+6
For some reason, attempting to route audio through QDSP6 on MSM8916 causes the RX interpolation path to get "stuck" after playing audio a few times. In this situation, the analog codec part is still working, but the RX path in the digital codec stops working, so you only hear the analog parts powering up. After a reboot everything works again. So far I was not able to reproduce the problem when using lpass-cpu. The downstream kernel driver avoids this by resetting the RX interpolation path after use. In mainline we do something similar for the TX decimator (LPASS_CDC_CLK_TX_RESET_B1_CTL), but the interpolator reset (LPASS_CDC_CLK_RX_RESET_CTL) got lost when the msm8916-wcd driver was split into analog and digital. Fix this problem by adding the reset to msm8916_wcd_digital_enable_interpolator(). Fixes: 150db8c5afa1 ("ASoC: codecs: Add msm8916-wcd digital codec") Cc: Srinivas Kandagatla <[email protected]> Signed-off-by: Stephan Gerhold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-13ASoC: msm8916-wcd-analog: Fix MIC BIAS Internal1Stephan Gerhold1-3/+13
MIC BIAS Internal1 is broken at the moment because we always enable the internal rbias resistor to the TX2 line (connected to the headset microphone), rather than enabling the resistor connected to TX1. Move the RBIAS code to pm8916_wcd_analog_enable_micbias_int1/2() to fix this. Fixes: 585e881e5b9e ("ASoC: codecs: Add msm8916-wcd analog codec") Cc: Srinivas Kandagatla <[email protected]> Signed-off-by: Stephan Gerhold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-13ASoC: cros_ec_codec: Make the device acpi compatibleYu-Hsuan Hsu1-0/+8
Add ACPI entry for cros_ec_codec. Signed-off-by: Yu-Hsuan Hsu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-13ASoC: sti: fix possible sleep-in-atomicArnaud Pouliquen1-3/+4
Change mutex and spinlock management to avoid sleep in atomic issue. Signed-off-by: Arnaud Pouliquen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-13ASoC: msm8916-wcd-analog: Fix selected events for MIC BIAS External1Stephan Gerhold1-2/+2
MIC BIAS External1 sets pm8916_wcd_analog_enable_micbias_ext1() as event handler, which ends up in pm8916_wcd_analog_enable_micbias_ext(). But pm8916_wcd_analog_enable_micbias_ext() only handles the POST_PMU event, which is not specified in the event flags for MIC BIAS External1. This means that the code in the event handler is never actually run. Set SND_SOC_DAPM_POST_PMU as the only event for the handler to fix this. Fixes: 585e881e5b9e ("ASoC: codecs: Add msm8916-wcd analog codec") Cc: Srinivas Kandagatla <[email protected]> Signed-off-by: Stephan Gerhold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-13ASoC: hdac_hda: Fix error in driver removal after failed probeKai Vehmanen1-1/+3
In case system has multiple HDA codecs, and codec probe fails for at least one but not all codecs, driver will end up cancelling a non-initialized timer context upon driver removal. Call trace of typical case: [ 60.593646] WARNING: CPU: 1 PID: 1147 at kernel/workqueue.c:3032 __flush_work+0x18b/0x1a0 [...] [ 60.593670] __cancel_work_timer+0x11f/0x1a0 [ 60.593673] hdac_hda_dev_remove+0x25/0x30 [snd_soc_hdac_hda] [ 60.593674] device_release_driver_internal+0xe0/0x1c0 [ 60.593675] bus_remove_device+0xd6/0x140 [ 60.593677] device_del+0x175/0x3e0 [ 60.593679] ? widget_tree_free.isra.7+0x90/0xb0 [snd_hda_core] [ 60.593680] snd_hdac_device_unregister+0x34/0x50 [snd_hda_core] [ 60.593682] snd_hdac_ext_bus_device_remove+0x2a/0x60 [snd_hda_ext_core] [ 60.593684] hda_dsp_remove+0x26/0x100 [snd_sof_intel_hda_common] [ 60.593686] snd_sof_device_remove+0x84/0xa0 [snd_sof] [ 60.593687] sof_pci_remove+0x10/0x30 [snd_sof_pci] [ 60.593689] pci_device_remove+0x36/0xb0 Signed-off-by: Kai Vehmanen <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-13ASoC: SOF: Intel: fix HDA codec driver probe with multiple controllersKai Vehmanen1-7/+12
In case system has multiple HDA controllers, it can happen that same HDA codec driver is used for codecs of multiple controllers. In this case, SOF may fail to probe the HDA driver and SOF initialization fails. SOF HDA code currently relies that a call to request_module() will also run device matching logic to attach driver to the codec instance. However if driver for another HDA controller was already loaded and it already loaded the HDA codec driver, this breaks current logic in SOF. In this case the request_module() SOF does becomes a no-op and HDA Codec driver is not attached to the codec instance sitting on the HDA bus SOF is controlling. Typical scenario would be a system with both external and internal GPUs, with driver of the external GPU loaded first. Fix this by adding similar logic as is used in legacy HDA driver where an explicit device_attach() call is done after request_module(). Also add logic to propagate errors reported by device_attach() back to caller. This also works in the case where drivers are not built as modules. Signed-off-by: Kai Vehmanen <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-13ASoC: SOF: Intel: lower print level to dbg if we will reinit DSPBard liao1-3/+3
We will reinit DSP in a loop when it fails to initialize the first time, as recommended. So, it is not an error before we finally give up. And reorder the trace to make it more readable. Signed-off-by: Bard liao <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-13USB: serial: simple: Add Motorola Solutions TETRA MTP3xxx and MTP85xxJerónimo Borque1-0/+2
Add device-ids for the Motorola Solutions TETRA radios MTP3xxx series and MTP85xx series $ lsusb -vd 0cad: Bus 001 Device 009: ID 0cad:9015 Motorola CGISS TETRA PEI interface Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0cad Motorola CGISS idProduct 0x9015 bcdDevice 24.16 iManufacturer 1 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0037 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 3 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Bus 001 Device 010: ID 0cad:9013 Motorola CGISS TETRA PEI interface Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0cad Motorola CGISS idProduct 0x9013 bcdDevice 24.16 iManufacturer 1 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0037 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 3 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Signed-off-by: Jerónimo Borque <[email protected]> Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2020-01-13drm/rockchip: fix integer type used for storing dp data rateTobias Schramm1-1/+1
commit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changes the type of variables used to store the display port data rate and number of lanes to u8. However u8 is not sufficient to store the link data rate of the display port. This commit reverts the type of data rate to unsigned int. Fixes: 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") Signed-off-by: Tobias Schramm <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-13drm/i915/gt: Mark ring->vma as active while pinnedChris Wilson1-3/+28
As we use the active state to keep the vma alive while we are reading its contents during GPU error capture, we need to mark the ring->vma as active during execution if we want to include the rinbuffer in the error state. Reported-by: Lionel Landwerlin <[email protected]> Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Lionel Landwerlin <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 8ccfc20a7d56d7e16510e6e068ffb7b43c3ac100) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-13drm/i915/gt: Mark context->state vma as active while pinnedChris Wilson1-0/+9
As we use the active state to keep the vma alive while we are reading its contents during GPU error capture, we need to mark the context->state vma as active during execution if we want to include it in the error state. Reported-by: Lionel Landwerlin <[email protected]> Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Lionel Landwerlin <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 1b8bfc57267213ddf7f0b03cbd4c40aa65b530d6) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-13drm/i915/gt: Skip trying to unbind in restore_ggtt_mappingsChris Wilson1-5/+2
Currently we first to try to unbind the VMA (and lazily rebind on next use) as an optimisation during restore_ggtt_mappings. Ideally, the only objects in the GGTT upon resume are the pinned kernel objects which can't be unbound and need to be restored. As the unbind interferes with the plan to mark those objects as active for error capture, forgo the optimisation. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 80e5351df13a5c4e9ecc14a58fa60c84d356ee87) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-13drm/i915: Add missing include file <linux/math64.h>YueHaibing1-0/+1
Fix build error: ./drivers/gpu/drm/i915/selftests/i915_random.h: In function i915_prandom_u32_max_state: ./drivers/gpu/drm/i915/selftests/i915_random.h:48:23: error: implicit declaration of function mul_u32_u32; did you mean mul_u64_u32_div? [-Werror=implicit-function-declaration] return upper_32_bits(mul_u32_u32(prandom_u32_state(state), ep_ro)); Reported-by: Hulk Robot <[email protected]> Fixes: 7ce5b6850b47 ("drm/i915/selftests: Use mul_u32_u32() for 32b x 32b -> 64b result") Signed-off-by: YueHaibing <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 62bf5465b26d1f502430b9c654be7d16bf2e242d) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-13iio: light: vcnl4000: Fix scale for vcnl4040Guido Günther1-1/+2
According to the data sheet the ambient sensor's scale is 0.12 lux/step (not 0.024 lux/step as used by vcnl4200) when the integration time is 80ms. The integration time is currently hardcoded in the driver to that value. See p. 8 in https://www.vishay.com/docs/84307/designingvcnl4040.pdf Fixes: 5a441aade5b3 ("iio: light: vcnl4000 add support for the VCNL4040 proximity and light sensor") Signed-off-by: Guido Günther <[email protected]> Reviewed-by: Marco Felsch <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-13iio: buffer: align the size of scan bytes to size of the largest elementLars Möllendorf1-1/+5
Previous versions of `iio_compute_scan_bytes` only aligned each element to its own length (i.e. its own natural alignment). Because multiple consecutive sets of scan elements are buffered this does not work in case the computed scan bytes do not align with the natural alignment of the first scan element in the set. This commit fixes this by aligning the scan bytes to the natural alignment of the largest scan element in the set. Fixes: 959d2952d124 ("staging:iio: make iio_sw_buffer_preenable much more general.") Signed-off-by: Lars Möllendorf <[email protected]> Reviewed-by: Lars-Peter Clausen <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-13iio: chemical: pms7003: fix unmet triggered buffer dependencyTomasz Duszynski1-0/+1
IIO triggered buffer depends on IIO buffer which is missing from Kconfig file. This should go unnoticed most of the time because there's a chance something else has already enabled buffers. In some rare cases though one might experience kbuild warnings about unmet direct dependencies and build failures due to missing symbols. Fix this by selecting IIO_BUFFER explicitly. Signed-off-by: Tomasz Duszynski <[email protected]> Fixes: a1d642266c14 ("iio: chemical: add support for Plantower PMS7003 sensor") Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-13iio: imu: st_lsm6dsx: Fix selection of ST_LSM6DS3_IDStephan Gerhold1-1/+2
At the moment, attempting to probe a device with ST_LSM6DS3_ID (e.g. using the st,lsm6ds3 compatible) fails with: st_lsm6dsx_i2c 1-006b: unsupported whoami [69] ... even though 0x69 is the whoami listed for ST_LSM6DS3_ID. This happens because st_lsm6dsx_check_whoami() also attempts to match unspecified (zero-initialized) entries in the "id" array. ST_LSM6DS3_ID = 0 will therefore match any entry in st_lsm6dsx_sensor_settings (here: the first), because none of them actually have all 12 entries listed in the "id" array. Avoid this by additionally checking if "name" is set, which is only set for valid entries in the "id" array. Note: Although the problem was introduced earlier it did not surface until commit 52f4b1f19679 ("iio: imu: st_lsm6dsx: add support for accel/gyro unit of lsm9ds1") because ST_LSM6DS3_ID was the first entry in st_lsm6dsx_sensor_settings. Fixes: d068e4a0f921 ("iio: imu: st_lsm6dsx: add support to multiple devices with the same settings") Cc: <[email protected]> # 5.4 Acked-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Stephan Gerhold <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-13iio: adc: ad7124: Fix DT channel configurationAlexandru Tachici1-7/+5
This patch fixes device tree channel configuration. ad7124 driver reads channels configuration from the device tree. It expects to find channel specifications as child nodes. Before this patch ad7124 driver assumed that the child nodes are parsed by for_each_available_child_of_node in the order 0,1,2,3... This is wrong and the real order of the children can be seen by running: dtc -I fs /sys/firmware/devicetree/base on the machine. For example, running this on an rpi 3B+ yields the real children order: 4,2,0,7,5,3,1,6 Before this patch the driver assigned the channel configuration like this: - 0 <- 4 - 1 <- 2 - 2 <- 0 ........ For example, the symptoms can be observed by connecting the 4th channel to a 1V tension and then reading the in_voltage0-voltage19_raw sysfs (multiplied of course by the scale) one would see that channel 0 measures 1V and channel 4 measures only noise. Now the driver uses the reg property of each child in order to correctly identify to which channel the parsed configuration belongs to. Fixes b3af341bbd966: ("iio: adc: Add ad7124 support") Signed-off-by: Alexandru Tachici <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-13cpuidle: teo: Fix intervals[] array indexing bugIkjoon Jang1-1/+1
Fix a simple bug in rotating array index. Fixes: b26bf6ab716f ("cpuidle: New timer events oriented governor for tickless systems") Signed-off-by: Ikjoon Jang <[email protected]> Cc: 5.1+ <[email protected]> # 5.1+ Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-01-13platform/x86: asus-wmi: Fix keyboard brightness cannot be set to 0Jian-Hong Pan1-7/+1
Some of ASUS laptops like UX431FL keyboard backlight cannot be set to brightness 0. According to ASUS' information, the brightness should be 0x80 ~ 0x83. This patch fixes it by following the logic. Fixes: e9809c0b9670 ("asus-wmi: add keyboard backlight support") Signed-off-by: Jian-Hong Pan <[email protected]> Reviewed-by: Daniel Drake <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2020-01-13ALSA: dice: fix fallback from protocol extension into limited functionalityTakashi Sakamoto1-1/+4
At failure of attempt to detect protocol extension, ALSA dice driver should be fallback to limited functionality. However it's not. This commit fixes it. Cc: <[email protected]> # v4.18+ Fixes: 58579c056c1c9 ("ALSA: dice: use extended protocol to detect available stream formats") Signed-off-by: Takashi Sakamoto <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-01-13ALSA: firewire-tascam: fix corruption due to spin lock without restoration ↵Takashi Sakamoto1-2/+3
in SoftIRQ context ALSA firewire-tascam driver can bring corruption due to spin lock without restoration of IRQ flag in SoftIRQ context. This commit fixes the bug. Cc: Scott Bahling <[email protected]> Cc: <[email protected]> # v4.21 Fixes: d7167422433c ("ALSA: firewire-tascam: queue events for change of control surface") Signed-off-by: Takashi Sakamoto <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-01-13platform/x86: intel_pmc_core: update Comet Lake platform driverHarry Pan1-0/+2
Adding new CML CPU model ID into platform driver support list. Signed-off-by: Harry Pan <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2020-01-13platform/x86: GPD pocket fan: Allow somewhat lower/higher temperature limitsHans de Goede1-1/+1
Allow the user to configure the fan to turn on / speed-up at lower thresholds then before (20 degrees Celcius as minimum instead of 40) and likewise also allow the user to delay the fan speeding-up till the temperature hits 90 degrees Celcius (was 70). Cc: Jason Anderson <[email protected]> Reported-by: Jason Anderson <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2020-01-13platform/x86: GPD pocket fan: Use default values when wrong modparams are givenHans de Goede1-6/+19
Use our default values when wrong module-parameters are given, instead of refusing to load. Refusing to load leaves the fan at the BIOS default setting, which is "Off". The CPU's thermal throttling should protect the system from damage, but not-loading is really not the best fallback in this case. This commit fixes this by re-setting module-parameter values to their defaults if they are out of range, instead of failing the probe with -EINVAL. Cc: [email protected] Cc: Jason Anderson <[email protected]> Reported-by: Jason Anderson <[email protected]> Fixes: 594ce6db326e ("platform/x86: GPD pocket fan: Use a min-speed of 2 while charging") Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2020-01-13platform/mellanox: fix potential deadlock in the tmfifo driverLiming Sun1-9/+10
This commit fixes the potential deadlock caused by the console Rx and Tx processing at the same time. Rx and Tx both take the console and tmfifo spinlock but in different order which causes potential deadlock. The fix is to use different tmfifo spinlock for Rx and Tx since they protect different resources and it's safe to split the lock. Below is the reported call trace when copying/pasting large string in the console. Rx: _raw_spin_lock_irqsave (hvc lock) __hvc_poll hvc_poll in_intr vring_interrupt mlxbf_tmfifo_rxtx_one_desc (tmfifo lock) mlxbf_tmfifo_rxtx mlxbf_tmfifo_work_rxtx Tx: _raw_spin_lock_irqsave (tmfifo lock) mlxbf_tmfifo_virtio_notify virtqueue_notify virtqueue_kick put_chars hvc_push hvc_write (hvc lock) ... do_tty_write tty_write Fixes: 1357dfd7261f ("platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc") Cc: <[email protected]> # 5.4+ Reviewed-by: David Woods <[email protected]> Signed-off-by: Liming Sun <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2020-01-13platform/x86: intel-ips: Use the correct style for SPDX License IdentifierNishad Kamdar2-2/+2
This patch corrects the SPDX License Identifier style in header files related to x86 Platform Specific Drivers. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used). Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46. Suggested-by: Joe Perches <[email protected]> Signed-off-by: Nishad Kamdar <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2020-01-13drm/virtio: add missing virtio_gpu_array_lock_resv callGerd Hoffmann1-0/+1
When submitting a fenced command we must lock the object reservations because virtio_gpu_queue_fenced_ctrl_buffer() unlocks after adding the fence. Reported-by: Jann Horn <[email protected]> Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Chia-I Wu <[email protected]> Tested-by: Jann Horn <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-13Merge 5.5-rc6 into staging-nextGreg Kroah-Hartman485-2350/+3773
We need the staging fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.