aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-09-10drm/udl: Fix inconsistent urbs.count value during udl_free_urb_list()Takashi Iwai2-20/+30
In the current design, udl_get_urb() may be called asynchronously during the driver freeing its URL list via udl_free_urb_list(). The problem is that the sync is determined by comparing the urbs.count and urbs.available fields, while we clear urbs.count field only once after udl_free_urb_list() finishes, i.e. during udl_free_urb_list(), the state becomes inconsistent. For fixing this inconsistency and also for hardening the locking scheme, this patch does a slight refactoring of the code around udl_get_urb() and udl_free_urb_list(). Now urbs.count is updated in the same spinlock at extracting a URB from the list in udl_free_url_list(). Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220908095115.23396-11-tiwai@suse.de
2022-09-10drm/udl: Fix potential URB leaksTakashi Iwai2-4/+9
A couple of error handlings forgot to process the URB completion. Those are both with WARN_ON() so should be visible, but we must fix them in anyway. Fixes: 7350b2a3fbc6 ("drm/udl: Replace BUG_ON() with WARN_ON()") Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220908095115.23396-10-tiwai@suse.de
2022-09-10drm/udl: Pass rectangle directly to udl_handle_damage()Takashi Iwai1-11/+8
Just for some code simplification. Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/87tu5iauw4.wl-tiwai@suse.de
2022-09-10drm/udl: Drop unneeded alignmentTakashi Iwai2-67/+1
The alignment of damaged area was needed for the original udlfb driver that tried to trim the superfluous copies between front and backend buffers and handle data in long int. It's not the case for udl DRM driver, hence we can omit the whole unneeded alignment, as well as the dead code. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220908095115.23396-8-tiwai@suse.de
2022-09-10drm/udl: Increase the default URB list size to 20Takashi Iwai1-1/+1
It seems that the current size (4) for the URB list is too small on some devices, and it resulted in the occasional stalls. Increase the default URB list size to 20 for working around it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220908095115.23396-7-tiwai@suse.de
2022-09-10drm/udl: Suppress error print for -EPROTO at URB completionTakashi Iwai1-0/+1
The driver may receive -EPROTO at the URB completion when the device gets disconnected, and it's a normal situation. Suppress the error print for that, too. Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220908095115.23396-6-tiwai@suse.de
2022-09-10Revert "drm/udl: Kill pending URBs at suspend and disconnect"Takashi Iwai3-26/+3
This reverts the recent fix commit e25d5954264d ("drm/udl: Kill pending URBs at suspend and disconnect") as it turned out to lead to potential hangup at a disconnection, and it doesn't help much for suspend/resume problem, either. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220908095115.23396-5-tiwai@suse.de
2022-09-10drm/udl: Enable damage clippingThomas Zimmermann1-0/+1
Call drm_plane_enable_fb_damage_clips() and give userspace a chance of minimizing the updated display area. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220908095115.23396-4-tiwai@suse.de
2022-09-10drm/udl: Add reset_resumeThomas Zimmermann3-1/+13
Implement the reset_resume callback of struct usb_driver. Set the standard channel when called. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220908095115.23396-3-tiwai@suse.de
2022-09-10drm/udl: Restore display mode on resumeTakashi Iwai1-3/+0
Restore the display mode whne resuming from suspend. Currently, the display remains dark. On resume, the CRTC's mode does not change, but the 'active' flag changes to 'true'. Taking this into account when considering a mode switch restores the display mode. The bug is reproducable by using Gnome with udl and observing the adapter's suspend/resume behavior. Actually, the whole check added in udl_simple_display_pipe_enable() about the crtc_state->mode_changed was bogus. We should drop the whole check and always apply the mode change in this function. [ tiwai -- Drop the mode_changed check entirely instead, per Daniel's suggestion ] Fixes: 997d33c35618 ("drm/udl: Inline DPMS code into CRTC enable and disable functions") Cc: <stable@vger.kernel.org> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220908095115.23396-2-tiwai@suse.de
2022-09-10Merge tag 's390-6.0-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxLinus Torvalds2-2/+3
Pull s390 fixes from Vasily Gorbik: - Fix absolute zero lowcore corruption on kdump when CPU0 is offline - Fix lowcore protection setup for offline CPU restart * tag 's390-6.0-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/smp: enforce lowcore protection on CPU restart s390/boot: fix absolute zero lowcore corruption on boot
2022-09-10Merge tag 'hwmon-for-v6.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-stagingLinus Torvalds4-213/+278
Pull hwmon fixes from Guenter Roeck: - Fix severe regression in asus-ec-sensors driver which resulted in EC driver failures - Fix various bugs in mr75203 driver - Fix byte order bug in tps23861 driver * tag 'hwmon-for-v6.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (asus-ec-sensors) autoload module via DMI data hwmon: (mr75203) enable polling for all VM channels hwmon: (mr75203) fix multi-channel voltage reading hwmon: (mr75203) fix voltage equation for negative source input hwmon: (mr75203) update pvt->v_num and vm_num to the actual number of used sensors hwmon: (mr75203) fix VM sensor allocation when "intel,vm-map" not defined dt-bindings: hwmon: (mr75203) fix "intel,vm-map" property to be optional hwmon: (tps23861) fix byte order in resistance register
2022-09-10cpufreq: intel_pstate: Add Tigerlake support in no-HWP modeDoug Smythies1-0/+1
Users may disable HWP in firmware, in which case intel_pstate wouldn't load unless the CPU model is explicitly supported. Add TIGERLAKE to the list of CPUs that can register intel_pstate while not advertising the HWP capability. Without this change, an TIGERLAKE in no-HWP mode could only use the acpi_cpufreq frequency scaling driver. See also commits: d8de7a44e11f: cpufreq: intel_pstate: Add Skylake servers support fbdc21e9b038: cpufreq: intel_pstate: Add Icelake servers support in no-HWP mode 706c5328851d: cpufreq: intel_pstate: Add Cometlake support in no-HWP mode Reported by: M. Cargi Ari <cagriari@pm.me> Signed-off-by: Doug Smythies <dsmythies@telus.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-10usb: typec: intel_pmc_mux: Use the helper acpi_dev_get_memory_resources()Heikki Krogerus1-10/+1
It removes the need to check the resource data type separately. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-10ACPI: resource: Skip IRQ override on Asus Vivobook K3402ZA/K3502ZATamim Khan1-0/+19
In the ACPI DSDT table for Asus VivoBook K3402ZA/K3502ZA IRQ 1 is described as ActiveLow; however, the kernel overrides it to Edge_High. This prevents the internal keyboard from working on these laptops. In order to fix this add these laptops to the skip_override_table so that the kernel does not override IRQ 1 to Edge_High. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216158 Reviewed-by: Hui Wang <hui.wang@canonical.com> Tested-by: Tamim Khan <tamim@fusetak.com> Tested-by: Sunand <sunandchakradhar@gmail.com> Signed-off-by: Tamim Khan <tamim@fusetak.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-10ACPI: LPSS: Use the helper acpi_dev_get_memory_resources()Heikki Krogerus1-8/+1
It removes the need to check the resource data type separately. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-10ACPI: APD: Use the helper acpi_dev_get_memory_resources()Heikki Krogerus1-8/+1
It removes the need to check the resource data type separately. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-10ACPI: resource: Add helper function acpi_dev_get_memory_resources()Heikki Krogerus2-0/+18
Wrapper function that finds all memory type resources by using acpi_dev_get_resources(). It removes the need for the drivers to check the resource data type separately. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-10ACPI: resource: Filter out the non memory resources in is_memory()Heikki Krogerus1-0/+3
This will generalise the function so it should become useful in more places. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-10ACPI: tables: FPDT: Don't call acpi_os_map_memory() on invalid phys addressHans de Goede1-0/+22
On a Packard Bell Dot SC (Intel Atom N2600 model) there is a FPDT table which contains invalid physical addresses, with high bits set which fall outside the range of the CPU-s supported physical address range. Calling acpi_os_map_memory() on such an invalid phys address leads to the below WARN_ON in ioremap triggering resulting in an oops/stacktrace. Add code to verify the physical address before calling acpi_os_map_memory() to fix / avoid the oops. [ 1.226900] ioremap: invalid physical address 3001000000000000 [ 1.226949] ------------[ cut here ]------------ [ 1.226962] WARNING: CPU: 1 PID: 1 at arch/x86/mm/ioremap.c:200 __ioremap_caller.cold+0x43/0x5f [ 1.226996] Modules linked in: [ 1.227016] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc3+ #490 [ 1.227029] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 1.227038] RIP: 0010:__ioremap_caller.cold+0x43/0x5f [ 1.227054] Code: 96 00 00 e9 f8 af 24 ff 89 c6 48 c7 c7 d8 0c 84 99 e8 6a 96 00 00 e9 76 af 24 ff 48 89 fe 48 c7 c7 a8 0c 84 99 e8 56 96 00 00 <0f> 0b e9 60 af 24 ff 48 8b 34 24 48 c7 c7 40 0d 84 99 e8 3f 96 00 [ 1.227067] RSP: 0000:ffffb18c40033d60 EFLAGS: 00010286 [ 1.227084] RAX: 0000000000000032 RBX: 3001000000000000 RCX: 0000000000000000 [ 1.227095] RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00000000ffffffff [ 1.227105] RBP: 3001000000000000 R08: 0000000000000000 R09: ffffb18c40033c18 [ 1.227115] R10: 0000000000000003 R11: ffffffff99d62fe8 R12: 0000000000000008 [ 1.227124] R13: 0003001000000000 R14: 0000000000001000 R15: 3001000000000000 [ 1.227135] FS: 0000000000000000(0000) GS:ffff913a3c080000(0000) knlGS:0000000000000000 [ 1.227146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.227156] CR2: 0000000000000000 CR3: 0000000018c26000 CR4: 00000000000006e0 [ 1.227167] Call Trace: [ 1.227176] <TASK> [ 1.227185] ? acpi_os_map_iomem+0x1c9/0x1e0 [ 1.227215] ? kmem_cache_alloc_trace+0x187/0x370 [ 1.227254] acpi_os_map_iomem+0x1c9/0x1e0 [ 1.227288] acpi_init_fpdt+0xa8/0x253 [ 1.227308] ? acpi_debugfs_init+0x1f/0x1f [ 1.227339] do_one_initcall+0x5a/0x300 [ 1.227406] ? rcu_read_lock_sched_held+0x3f/0x80 [ 1.227442] kernel_init_freeable+0x28b/0x2cc [ 1.227512] ? rest_init+0x170/0x170 [ 1.227538] kernel_init+0x16/0x140 [ 1.227552] ret_from_fork+0x1f/0x30 [ 1.227639] </TASK> [ 1.227647] irq event stamp: 186819 [ 1.227656] hardirqs last enabled at (186825): [<ffffffff98184a6e>] __up_console_sem+0x5e/0x70 [ 1.227672] hardirqs last disabled at (186830): [<ffffffff98184a53>] __up_console_sem+0x43/0x70 [ 1.227686] softirqs last enabled at (186576): [<ffffffff980fbc9d>] __irq_exit_rcu+0xed/0x160 [ 1.227701] softirqs last disabled at (186569): [<ffffffff980fbc9d>] __irq_exit_rcu+0xed/0x160 [ 1.227715] ---[ end trace 0000000000000000 ]--- Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-10Merge tag 'dma-mapping-6.0-2022-09-10' of git://git.infradead.org/users/hch/dma-mappingLinus Torvalds4-18/+9
Pull dma-mapping fixes from Christoph Hellwig: - revert a panic on swiotlb initialization failure (Yu Zhao) - fix the lookup for partial syncs in dma-debug (Robin Murphy) - fix a shift overflow in swiotlb (Chao Gao) - fix a comment typo in swiotlb (Chao Gao) - mark a function static now that all abusers are gone (Christoph Hellwig) * tag 'dma-mapping-6.0-2022-09-10' of git://git.infradead.org/users/hch/dma-mapping: dma-mapping: mark dma_supported static swiotlb: fix a typo swiotlb: avoid potential left shift overflow dma-debug: improve search for partial syncs Revert "swiotlb: panic if nslabs is too small"
2022-09-10rockchip: add rockchip,rk3128-spiJohan Jonker1-0/+1
Add rockchip,rk3128-spi compatible string. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/c05fb9a3-ebf7-adec-e8ca-bd137d157f50@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-10spi: Merge tag 'v6.0-rc4' into spi-6.1Mark Brown327-1756/+3073
Linux 6.0-rc4 so we can test on BeagleBone again.
2022-09-10ALSA: hda: Fix hang at HD-audio codec unbinding due to refcount saturationTakashi Iwai1-2/+2
We fixed the potential deadlock at dynamic unbinding the HD-audio codec at the commit 7206998f578d ("ALSA: hda: Fix potential deadlock at codec unbinding"), but ironically, this caused another potential deadlock. The current code uses refcount_dec() and waits for the pending task with wait_event for dropping the refcount to 0. This works fine when PCMs are assigned and actually waiting for the refcount drop. Meanwhile, when there was no PCM assigned, the refcount_dec() call itself was supposed to drop to zero -- alas, it doesn't in reality; refcount_dec() complains, spews kernel warning and it saturates instead of dropping to 0, due to the nature of refcount_dec() implementation. This eventually blocks the wait_event() wakeup and the code get stuck there. For avoiding the problem, we call refcount_dec_and_test() and skips the sync-wait if it already reaches to zero. The patch does a slight code reshuffling to make sure to invoke other disconnect calls before the sync-wait, too. Fixes: 7206998f578d ("ALSA: hda: Fix potential deadlock at codec unbinding") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/YxtflWQnslMHVlU7@intel.com Link: https://lore.kernel.org/r/20220910142550.28494-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-10arm64: mm: fix resume for 52-bit enabled buildsJoey Gouly1-0/+3
__cpu_setup() was changed to take the actual number of VA bits in x0, however the resume path was not updated at the same time. Load `vabits_actual` in the resume path, to ensure that the correct number of VA bits is used. This fixes booting v6.0-rc kernels on my Juno. Signed-off-by: Joey Gouly <joey.gouly@arm.com> Fixes: 0aaa68532e9d ("arm64: mm: fix booting with 52-bit address space") Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20220909124311.38489-1-joey.gouly@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2022-09-10leds: simatic-ipc-leds-gpio: Make simatic_ipc_led_gpio_table staticHans de Goede1-1/+1
simatic_ipc_led_gpio_table is only used inside simatic-ipc-leds-gpio.c, make it static. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220910085836.84962-1-hdegoede@redhat.com
2022-09-10platform/x86: asus-wmi: Make kbd_rgb_mode_groups staticHans de Goede1-1/+1
kbd_rgb_mode_groups is only used inside asus-wmi.c, make it static. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220909210950.385398-1-hdegoede@redhat.com
2022-09-10asm-generic: Remove empty #ifdef SA_RESTORERChristophe Leroy1-2/+0
There was a #ifdef SA_RESTORER to guard the sa_restorer field in struct sigaction. Commit 8a1ab3155c2a ("UAPI: (Scripted) Disintegrate include/asm-generic") moved that struct into uapi/asm-generic/signal.h but the #ifdef SA_RESTORER remained. Remove it. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-09-10parisc: Use the generic IO helpersLinus Walleij1-89/+43
This enables the parisc to use <asm-generic/io.h> to fill in the missing (undefined) [read|write]sq I/O accessor functions. This is needed if parisc[64] ever wants to uses CONFIG_REGMAP_MMIO which has been patches to use accelerated _noinc accessors such as readsq/writesq that parisc64, while being a 64bit platform, as of now not yet provide. This comes with the requirement that everything the architecture already provides needs to be defined, rather than just being, say, static inline functions. Bite the bullet and just provide the definitions and make it work. Compile-tested on parisc32 and parisc64. Drop some of the __raw functions that now get implemented in <asm-generic/io.h>. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com> Cc: Helge Deller <deller@gmx.de> Cc: linux-parisc@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: Mark Brown <broonie@kernel.org> Cc: John David Anglin <dave.anglin@bell.net> Link: https://lore.kernel.org/linux-arm-kernel/62fcc351.hAyADB%2FY8JTxz+kh%25lkp@intel.com/ Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-09-10parisc: Remove 64bit access on 32bit machinesLinus Walleij2-2/+28
The parisc was using some readq/writeq accessors without special considerations as to what will happen on 32bit CPUs if you do this. Maybe we have been lucky that it "just worked" on 32bit due to the compiler behaviour, or the code paths were never executed. Fix the two offending code sites like this: arch/parisc/lib/iomap.c: - Put ifdefs around the 64bit accessors and make sure that ioread64, ioread64be, iowrite64 and iowrite64be are not available on 32bit builds. - Also fold in a bug fix where 64bit access was by mistake using 32bit writel() accessors rather than 64bit writeq(). drivers/parisc/sba_iommu.c: - Access any 64bit registers using _lo_hi-semantics by way of the readq and writeq operations provided by <linux/io-64-nonatomic-lo-hi.h> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com> Cc: Helge Deller <deller@gmx.de> Cc: linux-parisc@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: Arnd Bergmann <arnd@arndb.de> Cc: John David Anglin <dave.anglin@bell.net> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-09-10wifi: ath11k: Increase TCL data ring size for WCN6750Manikanta Pubbisetty4-1/+11
Increase TCL data ring size to 2048 for WCN6750. This is needed to meet 160 MHz TX throughput. Add a new hw_param to indicate the TX ring size for individual devices. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220905071805.31625-4-quic_mpubbise@quicinc.com
2022-09-10wifi: ath11k: Add multi TX ring support for WCN6750Manikanta Pubbisetty10-30/+175
Currently in the case of WCN6750, only one TCL ring is used for TX, this is limiting the TX throughput in 160 MHz case, enabling multiple TCL rings on WCN6750 has shown an improvement of nearly 300 Mbps in the case of TCP TX, therefore add the support of multi TX ring for WCN6750. Currently TCL ring is selected based on CPU ID, this logic cannot be applied for WCN6750 as there is chance of out of order TX of packets and to avoid this, choose TCL ring based on flow hash so that packets of the same flow will end up on same TCL ring. For the same reason, TCL ring retry logic is also not applicable for WCN6750. Also the mapping of TCL, WBM & RBM IDs for WCN6750 is different from existing devices. Create a new TCM/WBM/RBM mapping for WCN6750. Change does not impact existing ath11k devices. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220905071805.31625-3-quic_mpubbise@quicinc.com
2022-09-10wifi: ath11k: Enable threaded NAPIManikanta Pubbisetty2-0/+2
Enable threaded NAPI on all ath11k targets. Unlike traditional NAPI poll which runs in softirq context and on the core which scheduled the NAPI, threaded NAPI makes use of kernel threads which are under direct control of the scheduler and helps in balancing the NAPI processing load across multiple CPUs thereby improving throughput. In the case of WCN6750, enabling threaded NAPI has improved 160 MHz RX throughput by nearly 400 Mbps. Similar gains can be expected on other ath11k devices as well. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220905071805.31625-2-quic_mpubbise@quicinc.com
2022-09-10wifi: ath11k: mhi: fix potential memory leak in ath11k_mhi_register()Jianglei Nie1-7/+10
mhi_alloc_controller() allocates a memory space for mhi_ctrl. When gets some error, mhi_ctrl should be freed with mhi_free_controller(). But when ath11k_mhi_read_addr_from_dt() fails, the function returns without calling mhi_free_controller(), which will lead to a memory leak. We can fix it by calling mhi_free_controller() when ath11k_mhi_read_addr_from_dt() fails. Signed-off-by: Jianglei Nie <niejianglei2021@163.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220907073704.58806-1-niejianglei2021@163.com
2022-09-10wifi: ath11k: implement SRAM dump debugfs interfaceBaochen Qiang8-0/+138
On-board SRAM contains valuable information for firmware debugging so add a new file named "sram" to debugfs with which we can dump SRAM content using following the following: cp /sys/kernel/debug/ath11k/wcn6855\ hw2.0/sram /tmp/sram Currently this feature is enabled for QCA6390 and WCN6855. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220802075533.1744-3-quic_bqiang@quicinc.com
2022-09-10wifi: ath11k: Split PCI write/read functionsBaochen Qiang1-18/+32
ath11k_pcic_write32/read32 tries to do wake up before doing actual write/read work, which means each time a u32 is written/read, wake up is performed. This is not necessary in case where we do a large amount of write/read, because only one time of wake up is needed. So split each one into two parts, the first part does wake up and release, and the second one does actual write/read work. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220802075533.1744-2-quic_bqiang@quicinc.com
2022-09-09ipmi:ipmb: Don't call ipmi_unregister_smi() on a register failureCorey Minyard1-4/+8
The data structure won't be set up to be unregistered, and it can result in crashes if the register fails. Signed-off-by: Corey Minyard <minyard@acm.org>
2022-09-10arm64: dts: rockchip: use BCLK to GPIO switch on rk3399Judy Hsiao2-1/+34
We discoverd that the state of BCLK on, LRCLK off and SD_MODE on may cause the speaker melting issue. Removing LRCLK while BCLK is present can cause unexpected output behavior including a large DC output voltage as described in the Max98357a datasheet. In order to: 1. prevent BCLK from turning on by other component. 2. keep BCLK and LRCLK being present at the same time This patch adjusts the device tree to allow BCLK to switch to GPIO func before LRCLK output, and switch back during LRCLK is output. Signed-off-by: Judy Hsiao <judyhsiao@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20220708080726.4170711-1-judyhsiao@chromium.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-10arm64: dts: rockchip: Add Hantro encoder node to rk356xNicolas Frattaroli1-0/+20
The RK3566 and RK3568 come with a dedicated Hantro instance solely for encoding. This patch adds a node for this to the device tree, along with a node for its MMU. Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Link: https://lore.kernel.org/r/20220612155346.16288-4-frattaroli.nicolas@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-10arm64: dts: rockchip: Add VPU support for RK3568/RK3566Piotr Oniszczuk1-0/+20
RK356x has Hantro G1 video decoder capable to decode MPEG2/H.264/VP8 video formats. This patch enables RK356x video decoder in RK356x device-tree include. Tested on [1] with FFmpeg v4l2_request code taken from [2] with MPEG2, H.642 and VP8 samples with results [3]. [1] https://github.com/warpme/minimyth2 [2] https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-request/ffmpeg-001-v4l2-request.patch [3] https://github.com/warpme/minimyth2/blob/master/video-test-summary.txt Signed-off-by: Piotr Oniszczuk <piotr.oniszczuk@gmail.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Link: https://lore.kernel.org/r/20220214212955.1178947-2-piotr.oniszczuk@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-10arm64: dts: rockchip: Enable PCIe controller on rock3aChukun Pan1-0/+34
Add the nodes to enable the PCIe controller on the Radxa ROCK3 Model A board. Run test with the MT7921 pcie wireless card. Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20220726023516.6487-1-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-10arm64: dts: rockchip: add rtc to rock3aChukun Pan1-0/+23
Add devicetree node for hym8563 rtc to Radxa ROCK3 Model A board. Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20220726023046.5876-1-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-10arm64: dts: rockchip: Add PCIe 2 nodes to quartz64-bNicolas Frattaroli1-0/+34
This adds the regulator node to the quartz64-b device tree, and enables the PCIe 2 controller and combphy for it. Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Link: https://lore.kernel.org/r/20220718033145.792657-1-frattaroli.nicolas@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-10ARM: dts: rockchip: restyle emac nodesJohan Jonker7-36/+51
The emac_rockchip.txt file is converted to YAML. Phy nodes are now a subnode of mdio, so restyle the emac nodes of rk3036/rk3066/rk3188. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20220603163539.537-3-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-10ARM: dts: rockchip: fix rk3036 emac node compatible stringJohan Jonker1-1/+1
The Linux kernel has no logic to decide which driver to probe first. To prevent race conditions remove the rk3036 emac node fall back compatible string. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20220603163539.537-2-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-09ASoC: mediatek: Set i2s clock sharing from machine driversMark Brown12-83/+180
Merge series from Nícolas F. R. A. Prado <nfraprado@collabora.com>: The i2s ports on MediaTek SoCs only support a single data lane. In order to achieve full-duplex operation thus two i2s ports, one for input and one for output, need to be used together and sharing a single clock from one of the ports. This clock sharing setting was previously read by the sound platform driver from the devicetree, but given that the input/output pairing is closely related to which codecs are connected to which ports, the machine sound driver can infer and set it, so that no DT property is required. At this point only mt8183-kukui was using the DT property, but given that this property was never documented, and that the API introduced in this series makes it obsolete, the undocumented DT property can safely be removed. This series adds a function to allow setting the i2s shared clocks, makes use of it in the machine drivers as required, and removes the no longer required DT properties and support for them in the drivers, for all of mt8192, mt8183 and mt8186. Nícolas F. R. A. Prado (10): ASoC: mediatek: mt8192: Allow setting shared clocks from machine driver ASoC: mediatek: mt8192-mt6359: Make i2s9 share the clock from i2s8 ASoC: mediatek: mt8192: Remove clock share parsing from DT ASoC: mediatek: mt8183: Allow setting shared clocks from machine driver ASoC: mediatek: mt8183: Configure shared clocks ASoC: mediatek: mt8183: Remove clock share parsing from DT arm64: dts: mediatek: kukui: Remove i2s-share properties ASoC: mediatek: mt8186: Allow setting shared clocks from machine driver ASoC: mediatek: mt8186: Configure shared clocks ASoC: mediatek: mt8186: Remove clock share parsing from DT .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 -- sound/soc/mediatek/mt8183/mt8183-afe-common.h | 3 ++ .../mediatek/mt8183/mt8183-da7219-max98357.c | 33 +++++++++++++ sound/soc/mediatek/mt8183/mt8183-dai-i2s.c | 45 ++++++++--------- .../mt8183/mt8183-mt6358-ts3a227-max98357.c | 33 +++++++++++++ sound/soc/mediatek/mt8186/mt8186-afe-common.h | 3 ++ sound/soc/mediatek/mt8186/mt8186-dai-i2s.c | 44 ++++++++--------- .../mt8186/mt8186-mt6366-da7219-max98357.c | 18 +++++++ .../mt8186/mt8186-mt6366-rt1019-rt5682s.c | 18 +++++++ sound/soc/mediatek/mt8192/mt8192-afe-common.h | 3 ++ sound/soc/mediatek/mt8192/mt8192-dai-i2s.c | 49 ++++++++----------- .../mt8192/mt8192-mt6359-rt1015-rt5682.c | 9 ++++ 12 files changed, 180 insertions(+), 83 deletions(-) -- 2.37.3
2022-09-09Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds11-56/+47
Pull SCSI fixes from James Bottomley: "Eight patches which looks like quite a large core change, but most of the diffstat is reverting the attempt to rejig reference counting introduced in the last merge window which caused issues with device and module removal. Of the remaining four patches, only the fix use-after-free is substantial" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: mpt3sas: Fix use-after-free warning scsi: core: Fix a use-after-free scsi: core: Revert "Make sure that targets outlive devices" scsi: core: Revert "Make sure that hosts outlive targets" scsi: core: Revert "Simplify LLD module reference counting" scsi: core: Revert "Call blk_mq_free_tag_set() earlier" scsi: lpfc: Add missing destroy_workqueue() in error path scsi: lpfc: Return DID_TRANSPORT_DISRUPTED instead of DID_REQUEUE
2022-09-09regulator: tps65219: Fix .bypass_val_on settingAxel Lin1-1/+0
The .bypass_val_on setting does not match the .bypass_mask setting, so the .bypass_mask bit will never get set. Fix it by removing .bypass_val_on setting, the regulator_set_bypass_regmap and regulator_get_bypass_regmap helpers will use rdev->desc->bypass_mask as val_on if the val_on is 0. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20220828120153.1512508-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-09regulator: qcom_rpm: Fix circular deferral regressionLinus Walleij1-12/+12
On recent kernels, the PM8058 L16 (or any other PM8058 LDO-regulator) does not come up if they are supplied by an SMPS-regulator. This is not very strange since the regulators are registered in a long array and the L-regulators are registered before the S-regulators, and if an L-regulator defers, it will never get around to registering the S-regulator that it needs. See arch/arm/boot/dts/qcom-apq8060-dragonboard.dts: pm8058-regulators { (...) vdd_l13_l16-supply = <&pm8058_s4>; (...) Ooops. Fix this by moving the PM8058 S-regulators first in the array. Do the same for the PM8901 S-regulators (though this is currently not causing any problems with out device trees) so that the pattern of registration order is the same on all PMnnnn chips. Fixes: 087a1b5cdd55 ("regulator: qcom: Rework to single platform device") Cc: stable@vger.kernel.org Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konrad.dybcio@somainline.org> Cc: linux-arm-msm@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220909112529.239143-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-09regulator: core: Prevent integer underflowPatrick Rudolph1-1/+1
By using a ratio of delay to poll_enabled_time that is not integer time_remaining underflows and does not exit the loop as expected. As delay could be derived from DT and poll_enabled_time is defined in the driver this can easily happen. Use a signed iterator to make sure that the loop exits once the remaining time is negative. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Link: https://lore.kernel.org/r/20220909125954.577669-1-patrick.rudolph@9elements.com Signed-off-by: Mark Brown <broonie@kernel.org>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.