aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2022-04-13igc: Fix suspending when PTM is activeVinicius Costa Gomes1-1/+14
Some mainboard/CPU combinations, in particular, Alder Lake-S with a W680 mainboard, have shown problems (system hangs usually, no kernel logs) with suspend/resume when PCIe PTM is enabled and active. In some cases, it could be reproduced when removing the igc module. The best we can do is to stop PTM dialogs from the downstream/device side before the interface is brought down. PCIe PTM will be re-enabled when the interface is being brought up. Fixes: a90ec8483732 ("igc: Add support for PTP getcrosststamp()") Signed-off-by: Vinicius Costa Gomes <[email protected]> Tested-by: Naama Meir <[email protected]> Acked-by: Paul Menzel <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2022-04-13spi: atmel-quadspi: Fix the buswidth adjustment between spi-mem and controllerTudor Ambarus1-0/+3
Use the spi_mem_default_supports_op() core helper in order to take into account the buswidth specified by the user in device tree. Cc: <[email protected]> Fixes: 0e6aae08e9ae ("spi: Add QuadSPI driver for Atmel SAMA5D2") Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-04-13igc: Fix BUG: scheduling while atomicSasha Neftin1-2/+2
Replace usleep_range() method with udelay() method to allow atomic contexts in low-level MDIO access functions. The following issue can be seen by doing the following: $ modprobe -r bonding $ modprobe -v bonding max_bonds=1 mode=1 miimon=100 use_carrier=0 $ ip link set bond0 up $ ifenslave bond0 eth0 eth1 [ 982.357308] BUG: scheduling while atomic: kworker/u64:0/9/0x00000002 [ 982.364431] INFO: lockdep is turned off. [ 982.368824] Modules linked in: bonding sctp ip6_udp_tunnel udp_tunnel mlx4_ib ib_uverbs ib_core mlx4_en mlx4_core nfp tls sunrpc intel_rapl_msr iTCO_wdt iTCO_vendor_support mxm_wmi dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate intel_uncore pcspkr lpc_ich mei_me ipmi_ssif mei ipmi_si ipmi_devintf ipmi_msghandler wmi acpi_power_meter xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm ahci libahci crc32c_intel libata i2c_algo_bit tg3 megaraid_sas igc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: bonding] [ 982.437941] CPU: 25 PID: 9 Comm: kworker/u64:0 Kdump: loaded Tainted: G W --------- - - 4.18.0-348.el8.x86_64+debug #1 [ 982.451333] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 2.7.0 12/005/2017 [ 982.459791] Workqueue: bond0 bond_mii_monitor [bonding] [ 982.465622] Call Trace: [ 982.468355] dump_stack+0x8e/0xd0 [ 982.472056] __schedule_bug.cold.60+0x3a/0x60 [ 982.476919] __schedule+0x147b/0x1bc0 [ 982.481007] ? firmware_map_remove+0x16b/0x16b [ 982.485967] ? hrtimer_fixup_init+0x40/0x40 [ 982.490625] schedule+0xd9/0x250 [ 982.494227] schedule_hrtimeout_range_clock+0x10d/0x2c0 [ 982.500058] ? hrtimer_nanosleep_restart+0x130/0x130 [ 982.505598] ? hrtimer_init_sleeper_on_stack+0x90/0x90 [ 982.511332] ? usleep_range+0x88/0x130 [ 982.515514] ? recalibrate_cpu_khz+0x10/0x10 [ 982.520279] ? ktime_get+0xab/0x1c0 [ 982.524175] ? usleep_range+0x88/0x130 [ 982.528355] usleep_range+0xdd/0x130 [ 982.532344] ? console_conditional_schedule+0x30/0x30 [ 982.537987] ? igc_put_hw_semaphore+0x17/0x60 [igc] [ 982.543432] igc_read_phy_reg_gpy+0x111/0x2b0 [igc] [ 982.548887] igc_phy_has_link+0xfa/0x260 [igc] [ 982.553847] ? igc_get_phy_id+0x210/0x210 [igc] [ 982.558894] ? lock_acquire+0x34d/0x890 [ 982.563187] ? lock_downgrade+0x710/0x710 [ 982.567659] ? rcu_read_unlock+0x50/0x50 [ 982.572039] igc_check_for_copper_link+0x106/0x210 [igc] [ 982.577970] ? igc_config_fc_after_link_up+0x840/0x840 [igc] [ 982.584286] ? rcu_read_unlock+0x50/0x50 [ 982.588661] ? lock_release+0x591/0xb80 [ 982.592939] ? lock_release+0x591/0xb80 [ 982.597220] igc_has_link+0x113/0x330 [igc] [ 982.601887] ? lock_downgrade+0x710/0x710 [ 982.606362] igc_ethtool_get_link+0x6d/0x90 [igc] [ 982.611614] bond_check_dev_link+0x131/0x2c0 [bonding] [ 982.617350] ? bond_time_in_interval+0xd0/0xd0 [bonding] [ 982.623277] ? rcu_read_lock_held+0x62/0xc0 [ 982.627944] ? rcu_read_lock_sched_held+0xe0/0xe0 [ 982.633198] bond_mii_monitor+0x314/0x2500 [bonding] [ 982.638738] ? lock_contended+0x880/0x880 [ 982.643214] ? bond_miimon_link_change+0xa0/0xa0 [bonding] [ 982.649336] ? lock_acquire+0x34d/0x890 [ 982.653615] ? lock_downgrade+0x710/0x710 [ 982.658089] ? debug_object_deactivate+0x221/0x340 [ 982.663436] ? rcu_read_unlock+0x50/0x50 [ 982.667811] ? debug_print_object+0x2b0/0x2b0 [ 982.672672] ? __switch_to_asm+0x41/0x70 [ 982.677049] ? __switch_to_asm+0x35/0x70 [ 982.681426] ? _raw_spin_unlock_irq+0x24/0x40 [ 982.686288] ? trace_hardirqs_on+0x20/0x195 [ 982.690956] ? _raw_spin_unlock_irq+0x24/0x40 [ 982.695818] process_one_work+0x8f0/0x1770 [ 982.700390] ? pwq_dec_nr_in_flight+0x320/0x320 [ 982.705443] ? debug_show_held_locks+0x50/0x50 [ 982.710403] worker_thread+0x87/0xb40 [ 982.714489] ? process_one_work+0x1770/0x1770 [ 982.719349] kthread+0x344/0x410 [ 982.722950] ? kthread_insert_work_sanity_check+0xd0/0xd0 [ 982.728975] ret_from_fork+0x3a/0x50 Fixes: 5586838fe9ce ("igc: Add code for PHY support") Reported-by: Corinna Vinschen <[email protected]> Suggested-by: Dima Ruinskiy <[email protected]> Signed-off-by: Sasha Neftin <[email protected]> Tested-by: Corinna Vinschen <[email protected]> Tested-by: Naama Meir <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2022-04-13igc: Fix infinite loop in release_swfw_syncSasha Neftin1-2/+9
An infinite loop may occur if we fail to acquire the HW semaphore, which is needed for resource release. This will typically happen if the hardware is surprise-removed. At this stage there is nothing to do, except log an error and quit. Fixes: c0071c7aa5fe ("igc: Add HW initialization code") Suggested-by: Dima Ruinskiy <[email protected]> Signed-off-by: Sasha Neftin <[email protected]> Tested-by: Naama Meir <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2022-04-13spi: cadence-quadspi: fix incorrect supports_op() return valueMatthias Schiffer1-2/+17
Since the conversion to spi-mem, the driver advertised support for various operations that cqspi_set_protocol() was never expected to handle correctly - in particuar all non-DTR operations with command or address buswidth > 1. For DTR, all operations except for 8-8-8 would fail, as cqspi_set_protocol() returns -EINVAL. In non-DTR mode, this resulted in data corruption for SPI-NOR flashes that support such operations. As a minimal fix that can be backported to stable kernels, simply disallow the unsupported operations again to avoid this issue. Fixes: a314f6367787 ("mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework") Signed-off-by: Matthias Schiffer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-04-13net: dsa: realtek: don't parse compatible string for RTL8366SAlvin Šipraga1-5/+0
This switch is not even supported, but if someone were to actually put this compatible string "realtek,rtl8366s" in their device tree, they would be greeted with a kernel panic because the probe function would dereference NULL. So let's just remove it. Link: https://lore.kernel.org/all/CACRpkdYdKZs0WExXc3=0yPNOwP+oOV60HRz7SRoGjZvYHaT=1g@mail.gmail.com/ Signed-off-by: Alvin Šipraga <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-04-13net: dsa: realtek: fix Kconfig to assure consistent driver linkageAlvin Šipraga1-9/+21
The kernel test robot reported a build failure: or1k-linux-ld: drivers/net/dsa/realtek/realtek-smi.o:(.rodata+0x16c): undefined reference to `rtl8366rb_variant' ... with the following build configuration: CONFIG_NET_DSA_REALTEK=y CONFIG_NET_DSA_REALTEK_SMI=y CONFIG_NET_DSA_REALTEK_RTL8365MB=y CONFIG_NET_DSA_REALTEK_RTL8366RB=m The problem here is that the realtek-smi interface driver gets built-in, while the rtl8366rb switch subdriver gets built as a module, hence the symbol rtl8366rb_variant is not reachable when defining the OF device table in the interface driver. The Kconfig dependencies don't help in this scenario because they just say that the subdriver(s) depend on at least one interface driver. In fact, the subdrivers don't depend on the interface drivers at all, and can even be built even in their absence. Somewhat strangely, the interface drivers can also be built in the absence of any subdriver, BUT, if a subdriver IS enabled, then it must be reachable according to the linkage of the interface driver: effectively what the IS_REACHABLE() macro achieves. If it is not reachable, the above kind of linker error will be observed. Rather than papering over the above build error by simply using IS_REACHABLE(), we can do a little better and admit that it is actually the interface drivers that have a dependency on the subdrivers. So this patch does exactly that. Specifically, we ensure that: 1. The interface drivers' Kconfig symbols must have a value no greater than the value of any subdriver Kconfig symbols. 2. The subdrivers should by default enable both interface drivers, since most users probably want at least one of them; those interface drivers can be explicitly disabled however. What this doesn't do is prevent a user from building only a subdriver, without any interface driver. To that end, add an additional line of help in the menu to guide users in the right direction. Link: https://lore.kernel.org/all/[email protected]/ Reported-by: kernel test robot <[email protected]> Fixes: aac94001067d ("net: dsa: realtek: add new mdio interface for drivers") Signed-off-by: Alvin Šipraga <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-04-13spi: intel: Add support for Raptor Lake-S SPI serial flashMika Westerberg1-0/+1
Intel Raptor Lake-S has the same SPI serial flash controller as Alder Lake-P. Add Raptor Lake-S PCI ID to the driver list of supported devices. Signed-off-by: Mika Westerberg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-04-13Merge tag 'wireless-2022-04-13' of ↵David S. Miller5-23/+38
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Kalle Valo says: ==================== wireless fixes for v5.18 First set of fixes for v5.18. Maintainers file updates, two compilation warning fixes, one revert for ath11k and smaller fixes to drivers and stack. All the usual stuff. ==================== Signed-off-by: David S. Miller <[email protected]>
2022-04-13random: make random_get_entropy() return an unsigned longJason A. Donenfeld1-13/+7
Some implementations were returning type `unsigned long`, while others that fell back to get_cycles() were implicitly returning a `cycles_t` or an untyped constant int literal. That makes for weird and confusing code, and basically all code in the kernel already handled it like it was an `unsigned long`. I recently tried to handle it as the largest type it could be, a `cycles_t`, but doing so doesn't really help with much. Instead let's just make random_get_entropy() return an unsigned long all the time. This also matches the commonly used `arch_get_random_long()` function, so now RDRAND and RDTSC return the same sized integer, which means one can fallback to the other more gracefully. Cc: Dominik Brodowski <[email protected]> Cc: Theodore Ts'o <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-04-13random: allow partial reads if later user copies failJason A. Donenfeld1-10/+12
Rather than failing entirely if a copy_to_user() fails at some point, instead we should return a partial read for the amount that succeeded prior, unless none succeeded at all, in which case we return -EFAULT as before. This makes it consistent with other reader interfaces. For example, the following snippet for /dev/zero outputs "4" followed by "1": int fd; void *x = mmap(NULL, 4096, PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); assert(x != MAP_FAILED); fd = open("/dev/zero", O_RDONLY); assert(fd >= 0); printf("%zd\n", read(fd, x, 4)); printf("%zd\n", read(fd, x + 4095, 4)); close(fd); This brings that same standard behavior to the various RNG reader interfaces. While we're at it, we can streamline the loop logic a little bit. Suggested-by: Linus Torvalds <[email protected]> Cc: Jann Horn <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-04-13net: ftgmac100: access hardware register after clock readyDylan Hung1-5/+5
AST2600 MAC register 0x58 is writable only when the MAC clock is enabled. Usually, the MAC clock is enabled by the bootloader so register 0x58 is set normally when the bootloader is involved. To make ast2600 ftgmac100 work without the bootloader, postpone the register write until the clock is ready. Fixes: 137d23cea1c0 ("net: ftgmac100: Fix Aspeed ast2600 TX hang issue") Signed-off-by: Dylan Hung <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-04-13macvlan: Fix leaking skb in source mode with nodst optionMartin Willi1-2/+6
The MACVLAN receive handler clones skbs to all matching source MACVLAN interfaces, before it passes the packet along to match on destination based MACVLANs. When using the MACVLAN nodst mode, passing the packet to destination based MACVLANs is omitted and the handler returns with RX_HANDLER_CONSUMED. However, the passed skb is not freed, leaking for any packet processed with the nodst option. Properly free the skb when consuming packets to fix that leak. Fixes: 427f0c8c194b ("macvlan: Add nodst option to macvlan type source") Signed-off-by: Martin Willi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-04-13arm_pmu: Validate single/group leader eventsRob Herring1-6/+4
In the case where there is only a cycle counter available (i.e. PMCR_EL0.N is 0) and an event other than CPU cycles is opened, the open should fail as the event can never possibly be scheduled. However, the event validation when an event is opened is skipped when the group leader is opened. Fix this by always validating the group leader events. Reported-by: Al Grant <[email protected]> Cc: Will Deacon <[email protected]> Cc: Mark Rutland <[email protected]> Signed-off-by: Rob Herring <[email protected]> Acked-by: Mark Rutland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2022-04-13power: supply: Reset err after not finding static batteryYassine Oudjana1-0/+6
Otherwise power_supply_get_battery_info always returns -ENODEV on devices that do not have a static battery, even when a simple battery is found. Fixes: c8aee3f41cb8 ("power: supply: Static data for Samsung batteries") Signed-off-by: Yassine Oudjana <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]>
2022-04-13power: supply: samsung-sdi-battery: Add missing charge restart voltagesLinus Walleij1-0/+2
Two of the batteries were missing charging restart voltages, meaning they can drain if the algorithm relies on restarting charging at this voltage. Fix it up. Fixes: c8aee3f41cb8 ("power: supply: Static data for Samsung batteries") Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]>
2022-04-13phy: ti: omap-usb2: Fix error handling in omap_usb2_enable_clocksMiaoqian Lin1-1/+1
The corresponding API for clk_prepare_enable is clk_disable_unprepare. Make sure that the clock is unprepared on exit by changing clk_disable to clk_disable_unprepare. Fixes: ed31ee7cf1fe ("phy: ti: usb2: Fix logic on -EPROBE_DEFER") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2022-04-13drm/radeon: fix logic inversion in radeon_sync_resvChristian König1-1/+1
Shared is the opposite of write/exclusive. Signed-off-by: Christian König <[email protected]> Fixes: 0597ca7b43e4 ("drm/radeon: use new iterator in radeon_sync_resv") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1970 Reviewed-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-13bus: mhi: host: pci_generic: Flush recovery worker during freezeManivannan Sadhasivam1-0/+1
It is possible that the recovery work might be running while the freeze gets executed (during hibernation etc.,). Currently, we don't powerdown the stack if it is not up but if the recovery work completes after freeze, then the device will be up afterwards. This will not be a sane situation. So let's flush the recovery worker before trying to powerdown the device. Cc: [email protected] Fixes: 5f0c2ee1fe8d ("bus: mhi: pci-generic: Fix hibernation") Reported-by: Bhaumik Vasav Bhatt <[email protected]> Reviewed-by: Bhaumik Vasav Bhatt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]>
2022-04-13bus: mhi: host: pci_generic: Add missing poweroff() PM callbackManivannan Sadhasivam1-0/+1
During hibernation process, once thaw() stage completes, the MHI endpoint devices will be in M0 state post recovery. After that, the devices will be powered down so that the system can enter the target sleep state. During this stage, the PCI core will put the devices in D3hot. But this transition is allowed by the MHI spec. The devices can only enter D3hot when it is in M3 state. So for fixing this issue, let's add the poweroff() callback that will get executed before putting the system in target sleep state during hibernation. This callback will power down the device properly so that it could be restored during restore() or thaw() stage. Cc: [email protected] Fixes: 5f0c2ee1fe8d ("bus: mhi: pci-generic: Fix hibernation") Reported-by: Hemant Kumar <[email protected]> Suggested-by: Hemant Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]>
2022-04-12Merge tag 'media/v5.18-2' of ↵Linus Torvalds3-12/+13
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media fixes from Mauro Carvalho Chehab: - a regression fix for si2157 - a Kconfig dependency fix for imx-mipi-csis - fix the rockchip/rga driver probing logic * tag 'media/v5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: media: si2157: unknown chip version Si2147-A30 ROM 0x50 media: platform: imx-mipi-csis: Add dependency on VIDEO_DEV media: rockchip/rga: do proper error checking in probe
2022-04-12video: fbdev: mmp: replace usage of found with dedicated list iterator variableJakob Koschel1-6/+5
To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable instead of a found boolean [1]. This removes the need to use a found variable and simply checking if the variable was set, can determine if the break/goto was hit. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1] Signed-off-by: Jakob Koschel <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2022-04-12firmware: cs_dsp: Fix overrun of unterminated control name stringRichard Fitzgerald1-2/+1
For wmfw format v2 and later the coefficient name strings have a length field and are NOT null-terminated. Use kasprintf() to convert the unterminated string into a null-terminated string in an allocated buffer. The previous code handled this duplication incorrectly using kmemdup() and getting the length from a strlen() of the (unterminated) source string. This resulted in creating a string that continued up to the next byte in the firmware file that just happened to be 0x00. Signed-off-by: Richard Fitzgerald <[email protected]> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-04-12spi: spi-mtk-nor: initialize spi controller after resumeAllen-KH Cheng1-1/+11
After system resumes, the registers of nor controller are initialized with default values. The nor controller will not function properly. To handle both issues above, we add mtk_nor_init() in mtk_nor_resume after pm_runtime_force_resume(). Fixes: 3bfd9103c7af ("spi: spi-mtk-nor: Add power management support") Signed-off-by: Allen-KH Cheng <[email protected]> Reviewed-by: Rex-BC Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-04-12dmaengine: dw-edma: Fix unaligned 64bit accessHerve Codina1-2/+5
On some arch (ie aarch64 iMX8MM) unaligned PCIe accesses are not allowed and lead to a kernel Oops. [ 1911.668835] Unable to handle kernel paging request at virtual address ffff80001bc00a8c [ 1911.668841] Mem abort info: [ 1911.668844] ESR = 0x96000061 [ 1911.668847] EC = 0x25: DABT (current EL), IL = 32 bits [ 1911.668850] SET = 0, FnV = 0 [ 1911.668852] EA = 0, S1PTW = 0 [ 1911.668853] Data abort info: [ 1911.668855] ISV = 0, ISS = 0x00000061 [ 1911.668857] CM = 0, WnR = 1 [ 1911.668861] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000040ff4000 [ 1911.668864] [ffff80001bc00a8c] pgd=00000000bffff003, pud=00000000bfffe003, pmd=0068000018400705 [ 1911.668872] Internal error: Oops: 96000061 [#1] PREEMPT SMP ... The llp register present in the channel group registers is not aligned on 64bit. Fix unaligned 64bit access using two 32bit accesses Fixes: 04e0a39fc10f ("dmaengine: dw-edma: Add writeq() and readq() for 64 bits architectures") Signed-off-by: Herve Codina <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2022-04-12dmaengine: mediatek:Fix PM usage reference leak of ↵zhangqilong1-3/+6
mtk_uart_apdma_alloc_chan_resources pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it: 1) Replacing it with pm_runtime_resume_and_get to keep usage counter balanced. 2) Add putting operation before returning error. Fixes:9135408c3ace4 ("dmaengine: mediatek: Add MediaTek UART APDMA support") Signed-off-by: Zhang Qilong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2022-04-12bus: ti-sysc: Make omap3 gpt12 quirk handling SoC specificTony Lindgren1-1/+15
On beagleboard revisions A to B4 we need to use gpt12 as the system timer. However, the quirk handling added for gpt12 caused a regression for system suspend for am335x as the PM coprocessor needs the timers idled for suspend. Let's make the gpt12 quirk specific to omap34xx, other SoCs don't need it. Beagleboard revisions C and later no longer need to use the gpt12 related quirk. Then at some point, if we decide to drop support for the old beagleboard revisions A to B4, we can also drop the gpt12 related quirks completely. Fixes: 3ff340e24c9d ("bus: ti-sysc: Fix gpt12 system timer issue with reserved status") Reported-by: Kevin Hilman <[email protected]> Suggested-by: Kevin Hilman <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2022-04-12video: fbdev: sh_mobile_lcdcfb: Remove sh_mobile_lcdc_check_var() declarationGeert Uytterhoeven1-3/+0
As of commit 0fe66f327c464943 ("fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify"), there is no longer a need for a foward declaration of sh_mobile_lcdc_check_var(). Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2022-04-11Merge tag 'platform-drivers-x86-v5.18-2' of ↵Linus Torvalds6-52/+31
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform drivers fixes from Hans de Goede: - Documentation and compilation warning fixes - Kconfig dep fixes - Misc small code cleanups * tag 'platform-drivers-x86-v5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: amd-pmc: Fix compilation without CONFIG_SUSPEND platform/x86: acerhdf: Cleanup str_starts_with() Documentation/ABI: sysfs-class-firmware-attributes: Misc. cleanups Documentation/ABI: sysfs-class-firmware-attributes: Fix Sphinx errors Documentation/ABI: sysfs-driver-intel_sdsi: Fix sphinx warnings platform/x86: barco-p50-gpio: Fix duplicate included linux/io.h platform/x86: samsung-laptop: Fix an unsigned comparison which can never be negative platform/x86: think-lmi: certificate support clean ups
2022-04-11net: lan966x: Stop processing the MAC entry is port is wrong.Horatiu Vultur1-2/+4
Currently when getting a new MAC is learn, the HW generates an interrupt. So then the SW will check the new entry and checks if it arrived on a correct port. If it didn't just generate a warning. But this could still crash the system. Therefore stop processing that entry when an issue is seen. Fixes: 5ccd66e01cbef8 ("net: lan966x: add support for interrupts from analyzer") Signed-off-by: Horatiu Vultur <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-04-11net: lan966x: Fix when a port's upper is changed.Horatiu Vultur1-2/+1
On lan966x it is not allowed to have foreign interfaces under a bridge which already contains lan966x ports. So when a port leaves the bridge it would call switchdev_bridge_port_unoffload which eventually will notify the other ports that bridge left the vlan group but that is not true because the bridge is still part of the vlan group. Therefore when a port leaves the bridge, stop generating replays because already the HW cleared after itself and the other ports don't need to do anything else. Fixes: cf2f60897e921e ("net: lan966x: Add support to offload the forwarding.") Signed-off-by: Horatiu Vultur <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-04-11net: lan966x: Fix IGMP snooping when frames have vlan tagHoratiu Vultur1-0/+6
In case an IGMP frame has a vlan tag, then the function lan966x_hw_offload couldn't figure out that is a IGMP frame. Therefore the SW thinks that the frame was already forward by the HW which is not true. Extend lan966x_hw_offload to pop the vlan tag if are any and then check for IGMP frames. Fixes: 47aeea0d57e80c ("net: lan966x: Implement the callback SWITCHDEV_ATTR_ID_BRIDGE_MC_DISABLED ") Signed-off-by: Horatiu Vultur <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-04-11net: lan966x: Update lan966x_ptp_get_nominal_valueHoratiu Vultur1-4/+4
The clk_per_cfg register represents the value added to the system clock for each clock cycle. The issue is that the default value is wrong, meaning that in case the DUT was a grandmaster then everone in the network was too slow. In case there was a grandmaster, then there is no issue because the DUT will configure clk_per_cfg register based on the master frequency. Fixes: d096459494a887 ("net: lan966x: Add support for ptp clocks") Signed-off-by: Horatiu Vultur <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-04-11scsi: qedi: Fix failed disconnect handlingMike Christie1-35/+34
We set the qedi_ep state to EP_STATE_OFLDCONN_START when the ep is created. Then in qedi_set_path we kick off the offload work. If userspace times out the connection and calls ep_disconnect, qedi will only flush the offload work if the qedi_ep state has transitioned away from EP_STATE_OFLDCONN_START. If we can't connect we will not have transitioned state and will leave the offload work running, and we will free the qedi_ep from under it. This patch just has us init the work when we create the ep, then always flush it. Link: https://lore.kernel.org/r/[email protected] Tested-by: Manish Rangankar <[email protected]> Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Chris Leech <[email protected]> Acked-by: Manish Rangankar <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2022-04-11scsi: iscsi: Fix NOP handling during conn recoveryMike Christie1-1/+6
If a offload driver doesn't use the xmit workqueue, then when we are doing ep_disconnect libiscsi can still inject PDUs to the driver. This adds a check for if the connection is bound before trying to inject PDUs. Link: https://lore.kernel.org/r/[email protected] Tested-by: Manish Rangankar <[email protected]> Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2022-04-11scsi: iscsi: Merge suspend fieldsMike Christie5-16/+16
Move the tx and rx suspend fields into one flags field. Link: https://lore.kernel.org/r/[email protected] Tested-by: Manish Rangankar <[email protected]> Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2022-04-11scsi: iscsi: Fix unbound endpoint error handlingMike Christie1-29/+36
If a driver raises a connection error before the connection is bound, we can leave a cleanup_work queued that can later run and disconnect/stop a connection that is logged in. The problem is that drivers can call iscsi_conn_error_event for endpoints that are connected but not yet bound when something like the network port they are using is brought down. iscsi_cleanup_conn_work_fn will check for this and exit early, but if the cleanup_work is stuck behind other works, it might not get run until after userspace has done ep_disconnect. Because the endpoint is not yet bound there was no way for ep_disconnect to flush the work. The bug of leaving stop_conns queued was added in: Commit 23d6fefbb3f6 ("scsi: iscsi: Fix in-kernel conn failure handling") and: Commit 0ab710458da1 ("scsi: iscsi: Perform connection failure entirely in kernel space") was supposed to fix it, but left this case. This patch moves the conn state check to before we even queue the work so we can avoid queueing. Link: https://lore.kernel.org/r/[email protected] Fixes: 0ab710458da1 ("scsi: iscsi: Perform connection failure entirely in kernel space") Tested-by: Manish Rangankar <[email protected]> Reviewed-by: Lee Duncan <lduncan@@suse.com> Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2022-04-11scsi: iscsi: Fix conn cleanup and stop race during iscsid restartMike Christie1-0/+17
If iscsid is doing a stop_conn at the same time the kernel is starting error recovery we can hit a race that allows the cleanup work to run on a valid connection. In the race, iscsi_if_stop_conn sees the cleanup bit set, but it calls flush_work on the clean_work before iscsi_conn_error_event has queued it. The flush then returns before the queueing and so the cleanup_work can run later and disconnect/stop a conn while it's in a connected state. The patch: Commit 0ab710458da1 ("scsi: iscsi: Perform connection failure entirely in kernel space") added the late stop_conn call bug originally, and the patch: Commit 23d6fefbb3f6 ("scsi: iscsi: Fix in-kernel conn failure handling") attempted to fix it but only fixed the normal EH case and left the above race for the iscsid restart case. For the normal EH case we don't hit the race because we only signal userspace to start recovery after we have done the queueing, so the flush will always catch the queued work or see it completed. For iscsid restart cases like boot, we can hit the race because iscsid will call down to the kernel before the kernel has signaled any error, so both code paths can be running at the same time. This adds a lock around the setting of the cleanup bit and queueing so they happen together. Link: https://lore.kernel.org/r/[email protected] Fixes: 0ab710458da1 ("scsi: iscsi: Perform connection failure entirely in kernel space") Tested-by: Manish Rangankar <[email protected]> Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2022-04-11scsi: iscsi: Fix endpoint reuse regressionMike Christie1-1/+11
This patch fixes a bug where when using iSCSI offload we can free an endpoint while userspace still thinks it's active. That then causes the endpoint ID to be reused for a new connection's endpoint while userspace still thinks the ID is for the original connection. Userspace will then end up disconnecting a running connection's endpoint or trying to bind to another connection's endpoint. This bug is a regression added in: Commit 23d6fefbb3f6 ("scsi: iscsi: Fix in-kernel conn failure handling") where we added a in kernel ep_disconnect call to fix a bug in: Commit 0ab710458da1 ("scsi: iscsi: Perform connection failure entirely in kernel space") where we would call stop_conn without having done ep_disconnect. This early ep_disconnect call will then free the endpoint and it's ID while userspace still thinks the ID is valid. Fix the early release of the ID by having the in kernel recovery code keep a reference to the endpoint until userspace has called into the kernel to finish cleaning up the endpoint/connection. It requires the previous commit "scsi: iscsi: Release endpoint ID when its freed" which moved the freeing of the ID until when the endpoint is released. Link: https://lore.kernel.org/r/[email protected] Fixes: 23d6fefbb3f6 ("scsi: iscsi: Fix in-kernel conn failure handling") Tested-by: Manish Rangankar <[email protected]> Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2022-04-11scsi: iscsi: Release endpoint ID when its freedMike Christie1-36/+35
We can't release the endpoint ID until all references to the endpoint have been dropped or it could be allocated while in use. This has us use an idr instead of looping over all conns to find a free ID and then free the ID when all references have been dropped instead of when the device is only deleted. Link: https://lore.kernel.org/r/[email protected] Tested-by: Manish Rangankar <[email protected]> Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Chris Leech <[email protected]> Reviewed-by: Wu Bo <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2022-04-11scsi: iscsi: Fix offload conn cleanup when iscsid restartsMike Christie1-20/+28
When userspace restarts during boot or upgrades it won't know about the offload driver's endpoint and connection mappings. iscsid will start by cleaning up the old session by doing a stop_conn call. Later, if we are able to create a new connection, we clean up the old endpoint during the binding stage. The problem is that if we do stop_conn before doing the ep_disconnect call offload, drivers can still be executing I/O. We then might free tasks from the under the card/driver. This moves the ep_disconnect call to before we do the stop_conn call for this case. It will then work and look like a normal recovery/cleanup procedure from the driver's point of view. Link: https://lore.kernel.org/r/[email protected] Tested-by: Manish Rangankar <[email protected]> Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2022-04-11scsi: iscsi: Move iscsi_ep_disconnect()Mike Christie1-19/+19
This patch moves iscsi_ep_disconnect() so it can be called earlier in the next patch. Link: https://lore.kernel.org/r/[email protected] Tested-by: Manish Rangankar <[email protected]> Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2022-04-11scsi: pm80xx: Enable upper inbound, outbound queuesAjish Koshy1-0/+11
Executing driver on servers with more than 32 CPUs were faced with command timeouts. This is because we were not geting completions for commands submitted on IQ32 - IQ63. Set E64Q bit to enable upper inbound and outbound queues 32 to 63 in the MPI main configuration table. Added 500ms delay after successful MPI initialization as mentioned in controller datasheet. Link: https://lore.kernel.org/r/[email protected] Fixes: 05c6c029a44d ("scsi: pm80xx: Increase number of supported queues") Reviewed-by: Damien Le Moal <[email protected]> Acked-by: Jack Wang <[email protected]> Signed-off-by: Ajish Koshy <[email protected]> Signed-off-by: Viswas G <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2022-04-11scsi: pm80xx: Mask and unmask upper interrupt vectors 32-63Ajish Koshy1-9/+13
When upper inbound and outbound queues 32-63 are enabled, we see upper vectors 32-63 in interrupt service routine. We need corresponding registers to handle masking and unmasking of these upper interrupts. To achieve this, we use registers MSGU_ODMR_U(0x34) to mask and MSGU_ODMR_CLR_U(0x3C) to unmask the interrupts. In these registers bit 0-31 represents interrupt vectors 32-63. Link: https://lore.kernel.org/r/[email protected] Fixes: 05c6c029a44d ("scsi: pm80xx: Increase number of supported queues") Reviewed-by: John Garry <[email protected]> Acked-by: Jack Wang <[email protected]> Signed-off-by: Ajish Koshy <[email protected]> Signed-off-by: Viswas G <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2022-04-11Revert "scsi: scsi_debug: Address races following module load"Bart Van Assche1-146/+51
Revert the patch mentioned in the subject since it blocks I/O after module unload has started while this is a legitimate use case. For e.g. blktests test case srp/001 that patch causes a command timeout to be triggered for the following call stack: __schedule+0x4c3/0xd20 schedule+0x82/0x110 schedule_timeout+0x122/0x200 io_schedule_timeout+0x7b/0xc0 __wait_for_common+0x2bc/0x380 wait_for_completion_io_timeout+0x1d/0x20 blk_execute_rq+0x1db/0x200 __scsi_execute+0x1fb/0x310 sd_sync_cache+0x155/0x2c0 [sd_mod] sd_shutdown+0xbb/0x190 [sd_mod] sd_remove+0x5b/0x80 [sd_mod] device_remove+0x9a/0xb0 device_release_driver_internal+0x2c5/0x360 device_release_driver+0x12/0x20 bus_remove_device+0x1aa/0x270 device_del+0x2d4/0x640 __scsi_remove_device+0x168/0x1a0 scsi_forget_host+0xa8/0xb0 scsi_remove_host+0x9b/0x150 sdebug_driver_remove+0x3d/0x140 [scsi_debug] device_remove+0x6f/0xb0 device_release_driver_internal+0x2c5/0x360 device_release_driver+0x12/0x20 bus_remove_device+0x1aa/0x270 device_del+0x2d4/0x640 device_unregister+0x18/0x70 sdebug_do_remove_host+0x138/0x180 [scsi_debug] scsi_debug_exit+0x45/0xd5 [scsi_debug] __do_sys_delete_module.constprop.0+0x210/0x320 __x64_sys_delete_module+0x1f/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Link: https://lore.kernel.org/r/[email protected] Fixes: 2aad3cd85370 ("scsi: scsi_debug: Address races following module load") Cc: Douglas Gilbert <[email protected]> Cc: Yi Zhang <[email protected]> Cc: Bob Pearson <[email protected]> Reported-by: Yi Zhang <[email protected]> Tested-by: Yi Zhang <[email protected]> Acked-by: Douglas Gilbert <[email protected]> Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2022-04-11drm/msm/gpu: Avoid -Wunused-function with !CONFIG_PM_SLEEPNathan Chancellor1-5/+2
When building with CONFIG_PM=y and CONFIG_PM_SLEEP=n (such as ARCH=riscv allmodconfig), the following warnings/errors occur: drivers/gpu/drm/msm/adreno/adreno_device.c:679:12: error: 'adreno_system_resume' defined but not used [-Werror=unused-function] 679 | static int adreno_system_resume(struct device *dev) | ^~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/msm/adreno/adreno_device.c:655:12: error: 'adreno_system_suspend' defined but not used [-Werror=unused-function] 655 | static int adreno_system_suspend(struct device *dev) | ^~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors These functions are only used in SET_SYSTEM_SLEEP_PM_OPS(), which evaluates to empty when CONFIG_PM_SLEEP is not set, making these functions unused. To resolve this, use the SYSTEM_SLEEP_PM_OPS() and RUNTIME_PM_OPS() macros, which were introduced in commit 1a3c7bb08826 ("PM: core: Add new *_PM_OPS macros, deprecate old ones"). They are designed to avoid these compiler warnings while still guarding their use on CONFIG_PM{,_SLEEP}=y. Fixes: 7e4167c9e021 ("drm/msm/gpu: Park scheduler threads for system suspend") Signed-off-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2022-04-11Merge branch '100GbE' of ↵Jakub Kicinski4-23/+16
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-04-08 Alexander fixes a use after free issue with aRFS for ice driver. Mateusz reverts a commit that introduced issues related to device resets for iavf driver. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: Revert "iavf: Fix deadlock occurrence during resetting VF interface" ice: arfs: fix use-after-free when freeing @rx_cpu_rmap ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-04-11net: macb: Restart tx only if queue pointer is laggingTomas Melin1-0/+8
commit 4298388574da ("net: macb: restart tx after tx used bit read") added support for restarting transmission. Restarting tx does not work in case controller asserts TXUBR interrupt and TQBP is already at the end of the tx queue. In that situation, restarting tx will immediately cause assertion of another TXUBR interrupt. The driver will end up in an infinite interrupt loop which it cannot break out of. For cases where TQBP is at the end of the tx queue, instead only clear TX_USED interrupt. As more data gets pushed to the queue, transmission will resume. This issue was observed on a Xilinx Zynq-7000 based board. During stress test of the network interface, driver would get stuck on interrupt loop within seconds or minutes causing CPU to stall. Signed-off-by: Tomas Melin <[email protected]> Tested-by: Claudiu Beznea <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-04-11phy: ti: tusb1210: Fix an error handling path in tusb1210_probe()Christophe JAILLET1-2/+8
tusb1210_probe_charger_detect() must be undone by a corresponding tusb1210_remove_charger_detect() in the error handling path, as already done in the remove function. Fixes: 48969a5623ed ("phy: ti: tusb1210: Add charger detection") Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/07c4926c42243cedb3b6067a241bb486fdda01b5.1648991162.git.christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul <[email protected]>
2022-04-11phy: samsung: exynos5250-sata: fix missing device put in probe error pathsKrzysztof Kozlowski1-6/+14
The actions of of_find_i2c_device_by_node() in probe function should be reversed in error paths by putting the reference to obtained device. Fixes: bcff4cba41bc ("PHY: Exynos: Add Exynos5250 SATA PHY driver") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Alim Akhtar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.