Author: Mark Hasemeyer <[email protected]> Date: Wed Oct 18 17:59:31 2023 -0600 ALSA: hda: intel-dsp-config: Fix JSL Chromebook quirk detection commit 7c05b44e1a50d9cbfc4f731dddc436a24ddc129a upstream. Some Jasperlake Chromebooks overwrite the system vendor DMI value to the name of the OEM that manufactured the device. This breaks Chromebook quirk detection as it expects the system vendor to be "Google". Add another quirk detection entry that looks for "Google" in the BIOS version. Cc: [email protected] Signed-off-by: Mark Hasemeyer <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Max McCarthy <[email protected]> Date: Tue Oct 24 12:30:19 2023 +0000 ALSA: usb-audio: add quirk flag to enable native DSD for McIntosh devices commit 99248c8902f505ec064cf2b0f74629016f2f4c82 upstream. McIntosh devices supporting native DSD require the feature to be explicitly exposed. Add a flag that fixes an issue where DSD audio was defaulting to DSD over PCM instead of delivering raw DSD data. Signed-off-by: Max McCarthy <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/BL0PR13MB4433226005162D186A8DFF4AD6DFA@BL0PR13MB4433.namprd13.prod.outlook.com Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mark Hasemeyer <[email protected]> Date: Fri Oct 20 14:59:53 2023 -0600 ASoC: SOF: sof-pci-dev: Fix community key quirk detection commit 7dd692217b861a8292ff8ac2c9d4458538fd6b96 upstream. Some Chromebooks do not populate the product family DMI value resulting in firmware load failures. Add another quirk detection entry that looks for "Google" in the BIOS version. Theoretically, PRODUCT_FAMILY could be replaced with BIOS_VERSION, but it is left as a quirk to be conservative. Cc: [email protected] Signed-off-by: Mark Hasemeyer <[email protected]> Acked-by: Curtis Malainey <[email protected]> Link: https://lore.kernel.org/r/20231020145953.v1.1.Iaf5702dc3f8af0fd2f81a22ba2da1a5e15b3604c@changeid Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Janne Grunau <[email protected]> Date: Mon Oct 16 09:13:08 2023 +0200 Bluetooth: hci_bcm4377: Mark bcm4378/bcm4387 as BROKEN_LE_CODED commit 41e9cdea9c4ab6606ca462ff4ec901a82d022c05 upstream. bcm4378 and bcm4387 claim to support LE Coded PHY but fail to pair (reliably) with BLE devices if it is enabled. On bcm4378 pairing usually succeeds after 2-3 tries. On bcm4387 pairing appears to be completely broken. Cc: [email protected] # 6.4.y+ Link: https://discussion.fedoraproject.org/t/mx-master-3-bluetooth-mouse-doesnt-connect/87072/33 Link: https://github.com/AsahiLinux/linux/issues/177 Fixes: 288c90224eec ("Bluetooth: Enable all supported LE PHY by default") Signed-off-by: Janne Grunau <[email protected]> Reviewed-by: Eric Curtin <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nicholas Kazlauskas <[email protected]> Date: Wed Sep 27 15:06:41 2023 -0400 drm/amd/display: Don't use fsleep for PSR exit waits [ Upstream commit 79df45dc4bfb13d9bd3a75338b9d9dab948be3d6 ] [Why] These functions can be called from high IRQ levels and the OS will hang if it tries to use a usleep_highres or a msleep. [How] Replace the fsleep with a udelay. Reviewed-by: Aric Cyr <[email protected]> Acked-by: Tom Chung <[email protected]> Signed-off-by: Nicholas Kazlauskas <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Francesco Dolcini <[email protected]> Date: Thu Oct 19 17:48:34 2023 +0200 dt-bindings: serial: rs485: Add rs485-rts-active-high commit 0c01b20fb50ba63c03841aa83070dc59c3b1b02f upstream. Add rs485-rts-active-high property, this is a legacy property used by 8250_omap. This fixes the following make dt_binding_check warning: Documentation/devicetree/bindings/serial/8250_omap.yaml: rs485-rts-active-high: missing type definition Reported-by: Geert Uytterhoeven <[email protected]> Closes: https://lore.kernel.org/all/CAMuHMdUkPiA=o_QLyuwsTYW7y1ksCjHAqyNSHFx2QZ-dP-HGsQ@mail.gmail.com/ Fixes: 403e97d6ab2c ("dt-bindings: serial: 8250_omap: add rs485-rts-active-high") Cc: stable <[email protected]> Signed-off-by: Francesco Dolcini <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Steven Rostedt (Google) <[email protected]> Date: Sun Nov 5 10:56:34 2023 -0500 eventfs: Delete eventfs_inode when the last dentry is freed commit 020010fbfa202aa528a52743eba4ab0da3400a4e upstream There exists a race between holding a reference of an eventfs_inode dentry and the freeing of the eventfs_inode. If user space has a dentry held long enough, it may still be able to access the dentry's eventfs_inode after it has been freed. To prevent this, have he eventfs_inode freed via the last dput() (or via RCU if the eventfs_inode does not have a dentry). This means reintroducing the eventfs_inode del_list field at a temporary place to put the eventfs_inode. It needs to mark it as freed (via the list) but also must invalidate the dentry immediately as the return from eventfs_remove_dir() expects that they are. But the dentry invalidation must not be called under the eventfs_mutex, so it must be done after the eventfs_inode is marked as free (put on a deletion list). Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Ajay Kaher <[email protected]> Fixes: 5bdcd5f5331a2 ("eventfs: Implement removal of meta data from eventfs") Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Steven Rostedt (Google) <[email protected]> Date: Sun Nov 5 10:56:32 2023 -0500 eventfs: Remove "is_freed" union with rcu head commit f2f496370afcbc5227d7002da28c74b91fed12ff upstream The eventfs_inode->is_freed was a union with the rcu_head with the assumption that when it was on the srcu list the head would contain a pointer which would make "is_freed" true. But that was a wrong assumption as the rcu head is a single link list where the last element is NULL. Instead, split the nr_entries integer so that "is_freed" is one bit and the nr_entries is the next 31 bits. As there shouldn't be more than 10 (currently there's at most 5 to 7 depending on the config), this should not be a problem. Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Cc: Mark Rutland <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Ajay Kaher <[email protected]> Fixes: 63940449555e7 ("eventfs: Implement eventfs lookup, read, open functions") Reviewed-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Steven Rostedt (Google) <[email protected]> Date: Sun Nov 5 10:56:33 2023 -0500 eventfs: Save ownership and mode commit 28e12c09f5aa081b2d13d1340e3610070b6c624d upstream Now that inodes and dentries are created on the fly, they are also reclaimed on memory pressure. Since the ownership and file mode are saved in the inode, if they are freed, any changes to the ownership and mode will be lost. To counter this, if the user changes the permissions or ownership, save them, and when creating the inodes again, restore those changes. Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Cc: Ajay Kaher <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Andrew Morton <[email protected]> Fixes: 63940449555e7 ("eventfs: Implement eventfs lookup, read, open functions") Reviewed-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Steven Rostedt (Google) <[email protected]> Date: Sun Nov 5 10:56:35 2023 -0500 eventfs: Use simple_recursive_removal() to clean up dentries commit 407c6726ca71b33330d2d6345d9ea7ebc02575e9 upstream Looking at how dentry is removed via the tracefs system, I found that eventfs does not do everything that it did under tracefs. The tracefs removal of a dentry calls simple_recursive_removal() that does a lot more than a simple d_invalidate(). As it should be a requirement that any eventfs_inode that has a dentry, so does its parent. When removing a eventfs_inode, if it has a dentry, a call to simple_recursive_removal() on that dentry should clean up all the dentries underneath it. Add WARN_ON_ONCE() to check for the parent having a dentry if any children do. Link: https://lore.kernel.org/all/20231101022553.GE1957730@ZenIV/ Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Al Viro <[email protected]> Fixes: 5bdcd5f5331a2 ("eventfs: Implement removal of meta data from eventfs") Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Wed Nov 8 11:56:25 2023 +0100 Linux 6.6.1 Link: https://lore.kernel.org/r/[email protected] Tested-by: Ronald Warsow <[email protected]> Tested-by: SeongJae Park <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Allen Pais <[email protected]> Tested-by: Rudi Heitbaum <[email protected]> Tested-by: Bagas Sanjaya <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Takeshi Ogasawara <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Ricardo B. Marliere <[email protected]> Tested-by: Guenter Roeck <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Jon Hunter <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Siddharth Vadapalli <[email protected]> Date: Fri Oct 20 17:32:48 2023 +0530 misc: pci_endpoint_test: Add deviceID for J721S2 PCIe EP device support commit 8293703a492ae97c86af27c75b76e6239ec86483 upstream. Add DEVICE_ID for J721S2 and enable support for endpoints configured with this DEVICE_ID in the pci_endpoint_test driver. Signed-off-by: Siddharth Vadapalli <[email protected]> Cc: stable <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vicki Pfau <[email protected]> Date: Wed Sep 27 13:22:12 2023 -0700 PCI: Prevent xHCI driver from claiming AMD VanGogh USB3 DRD device commit 7e6f3b6d2c352b5fde37ce3fed83bdf6172eebd4 upstream. The AMD VanGogh SoC contains a DesignWare USB3 Dual-Role Device that can be operated as either a USB Host or a USB Device, similar to on the AMD Nolan platform. be6646bfbaec ("PCI: Prevent xHCI driver from claiming AMD Nolan USB3 DRD device") added a quirk to let the dwc3 driver claim the Nolan device since it provides more specific support. Extend that quirk to include the VanGogh SoC USB3 device. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vicki Pfau <[email protected]> [bhelgaas: include be6646bfbaec reference, add stable tag] Signed-off-by: Bjorn Helgaas <[email protected]> Cc: [email protected] # v3.19+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ian Rogers <[email protected]> Date: Fri Sep 15 20:56:40 2023 -0700 perf evlist: Avoid frequency mode for the dummy event [ Upstream commit f9cdeb58a9cf46c09b56f5f661ea8da24b6458c3 ] Dummy events are created with an attribute where the period and freq are zero. evsel__config will then see the uninitialized values and initialize them in evsel__default_freq_period. As fequency mode is used by default the dummy event would be set to use frequency mode. However, this has no effect on the dummy event but does cause unnecessary timers/interrupts. Avoid this overhead by setting the period to 1 for dummy events. evlist__add_aux_dummy calls evlist__add_dummy then sets freq=0 and period=1. This isn't necessary after this change and so the setting is removed. From Stephane: The dummy event is not counting anything. It is used to collect mmap records and avoid a race condition during the synthesize mmap phase of perf record. As such, it should not cause any overhead during active profiling. Yet, it did. Because of a bug the dummy event was programmed as a sampling event in frequency mode. Events in that mode incur more kernel overheads because on timer tick, the kernel has to look at the number of samples for each event and potentially adjust the sampling period to achieve the desired frequency. The dummy event was therefore adding a frequency event to task and ctx contexts we may otherwise not have any, e.g., perf record -a -e cpu/event=0x3c,period=10000000/. On each timer tick the perf_adjust_freq_unthr_context() is invoked and if ctx->nr_freq is non-zero, then the kernel will loop over ALL the events of the context looking for frequency mode ones. In doing, so it locks the context, and enable/disable the PMU of each hw event. If all the events of the context are in period mode, the kernel will have to traverse the list for nothing incurring overhead. The overhead is multiplied by a very large factor when this happens in a guest kernel. There is no need for the dummy event to be in frequency mode, it does not count anything and therefore should not cause extra overhead for no reason. Fixes: 5bae0250237f ("perf evlist: Introduce perf_evlist__new_dummy constructor") Reported-by: Stephane Eranian <[email protected]> Signed-off-by: Ian Rogers <[email protected]> Acked-by: Adrian Hunter <[email protected]> Cc: Yang Jihong <[email protected]> Cc: Kan Liang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kai-Heng Feng <[email protected]> Date: Wed Sep 13 11:32:33 2023 +0800 power: supply: core: Use blocking_notifier_call_chain to avoid RCU complaint [ Upstream commit bbaa6ffa5b6c9609d3b3c431c389b407eea5441f ] AMD PMF driver can cause the following warning: [ 196.159546] ------------[ cut here ]------------ [ 196.159556] Voluntary context switch within RCU read-side critical section! [ 196.159571] WARNING: CPU: 0 PID: 9 at kernel/rcu/tree_plugin.h:320 rcu_note_context_switch+0x43d/0x560 [ 196.159604] Modules linked in: nvme_fabrics ccm rfcomm snd_hda_scodec_cs35l41_spi cmac algif_hash algif_skcipher af_alg bnep joydev btusb btrtl uvcvideo btintel btbcm videobuf2_vmalloc intel_rapl_msr btmtk videobuf2_memops uvc videobuf2_v4l2 intel_rapl_common binfmt_misc hid_sensor_als snd_sof_amd_vangogh hid_sensor_trigger bluetooth industrialio_triggered_buffer videodev snd_sof_amd_rembrandt hid_sensor_iio_common amdgpu ecdh_generic kfifo_buf videobuf2_common hp_wmi kvm_amd sparse_keymap snd_sof_amd_renoir wmi_bmof industrialio ecc mc nls_iso8859_1 kvm snd_sof_amd_acp irqbypass snd_sof_xtensa_dsp crct10dif_pclmul crc32_pclmul mt7921e snd_sof_pci snd_ctl_led polyval_clmulni mt7921_common polyval_generic snd_sof ghash_clmulni_intel mt792x_lib mt76_connac_lib sha512_ssse3 snd_sof_utils aesni_intel snd_hda_codec_realtek crypto_simd mt76 snd_hda_codec_generic cryptd snd_soc_core snd_hda_codec_hdmi rapl ledtrig_audio input_leds snd_compress i2c_algo_bit drm_ttm_helper mac80211 snd_pci_ps hid_multitouch ttm drm_exec [ 196.159970] drm_suballoc_helper snd_rpl_pci_acp6x amdxcp drm_buddy snd_hda_intel snd_acp_pci snd_hda_scodec_cs35l41_i2c serio_raw gpu_sched snd_hda_scodec_cs35l41 snd_acp_legacy_common snd_intel_dspcfg snd_hda_cs_dsp_ctls snd_hda_codec libarc4 drm_display_helper snd_pci_acp6x cs_dsp snd_hwdep snd_soc_cs35l41_lib video k10temp snd_pci_acp5x thunderbolt snd_hda_core drm_kms_helper cfg80211 snd_seq snd_rn_pci_acp3x snd_pcm snd_acp_config cec snd_soc_acpi snd_seq_device rc_core ccp snd_pci_acp3x snd_timer snd soundcore wmi amd_pmf platform_profile amd_pmc mac_hid serial_multi_instantiate wireless_hotkey hid_sensor_hub sch_fq_codel msr parport_pc ppdev lp parport efi_pstore ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log cdc_ether usbnet r8152 mii hid_generic nvme i2c_hid_acpi i2c_hid nvme_core i2c_piix4 xhci_pci amd_sfh drm xhci_pci_renesas nvme_common hid [ 196.160382] CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.6.0-rc1 #4 [ 196.160397] Hardware name: HP HP EliteBook 845 14 inch G10 Notebook PC/8B6E, BIOS V82 Ver. 01.02.00 08/24/2023 [ 196.160405] Workqueue: events power_supply_changed_work [ 196.160426] RIP: 0010:rcu_note_context_switch+0x43d/0x560 [ 196.160440] Code: 00 48 89 be 40 08 00 00 48 89 86 48 08 00 00 48 89 10 e9 63 fe ff ff 48 c7 c7 10 e7 b0 9e c6 05 e8 d8 20 02 01 e8 13 0f f3 ff <0f> 0b e9 27 fc ff ff a9 ff ff ff 7f 0f 84 cf fc ff ff 65 48 8b 3c [ 196.160450] RSP: 0018:ffffc900001878f0 EFLAGS: 00010046 [ 196.160462] RAX: 0000000000000000 RBX: ffff88885e834040 RCX: 0000000000000000 [ 196.160470] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 196.160476] RBP: ffffc90000187910 R08: 0000000000000000 R09: 0000000000000000 [ 196.160482] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 196.160488] R13: 0000000000000000 R14: ffff888100990000 R15: ffff888100990000 [ 196.160495] FS: 0000000000000000(0000) GS:ffff88885e800000(0000) knlGS:0000000000000000 [ 196.160504] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 196.160512] CR2: 000055cb053c8246 CR3: 000000013443a000 CR4: 0000000000750ef0 [ 196.160520] PKRU: 55555554 [ 196.160526] Call Trace: [ 196.160532] <TASK> [ 196.160548] ? show_regs+0x72/0x90 [ 196.160570] ? rcu_note_context_switch+0x43d/0x560 [ 196.160580] ? __warn+0x8d/0x160 [ 196.160600] ? rcu_note_context_switch+0x43d/0x560 [ 196.160613] ? report_bug+0x1bb/0x1d0 [ 196.160637] ? handle_bug+0x46/0x90 [ 196.160658] ? exc_invalid_op+0x19/0x80 [ 196.160675] ? asm_exc_invalid_op+0x1b/0x20 [ 196.160709] ? rcu_note_context_switch+0x43d/0x560 [ 196.160727] __schedule+0xb9/0x15f0 [ 196.160746] ? srso_alias_return_thunk+0x5/0x7f [ 196.160765] ? srso_alias_return_thunk+0x5/0x7f [ 196.160778] ? acpi_ns_search_one_scope+0xbe/0x270 [ 196.160806] schedule+0x68/0x110 [ 196.160820] schedule_timeout+0x151/0x160 [ 196.160829] ? srso_alias_return_thunk+0x5/0x7f [ 196.160842] ? srso_alias_return_thunk+0x5/0x7f [ 196.160855] ? acpi_ns_lookup+0x3c5/0xa90 [ 196.160878] __down_common+0xff/0x220 [ 196.160905] __down_timeout+0x16/0x30 [ 196.160920] down_timeout+0x64/0x70 [ 196.160938] acpi_os_wait_semaphore+0x85/0x200 [ 196.160959] acpi_ut_acquire_mutex+0x9e/0x280 [ 196.160979] acpi_ex_enter_interpreter+0x2d/0xb0 [ 196.160992] acpi_ns_evaluate+0x2f0/0x5f0 [ 196.161005] acpi_evaluate_object+0x172/0x490 [ 196.161018] ? acpi_os_signal_semaphore+0x8a/0xd0 [ 196.161038] acpi_evaluate_integer+0x52/0xe0 [ 196.161055] ? kfree+0x79/0x120 [ 196.161071] ? srso_alias_return_thunk+0x5/0x7f [ 196.161089] acpi_ac_get_state.part.0+0x27/0x80 [ 196.161110] get_ac_property+0x5c/0x70 [ 196.161127] ? __pfx___power_supply_is_system_supplied+0x10/0x10 [ 196.161146] __power_supply_is_system_supplied+0x44/0xb0 [ 196.161166] class_for_each_device+0x124/0x160 [ 196.161184] ? acpi_ac_get_state.part.0+0x27/0x80 [ 196.161203] ? srso_alias_return_thunk+0x5/0x7f [ 196.161223] power_supply_is_system_supplied+0x3c/0x70 [ 196.161243] amd_pmf_get_power_source+0xe/0x20 [amd_pmf] [ 196.161276] amd_pmf_power_slider_update_event+0x49/0x90 [amd_pmf] [ 196.161310] amd_pmf_pwr_src_notify_call+0xe7/0x100 [amd_pmf] [ 196.161340] notifier_call_chain+0x5f/0xe0 [ 196.161362] atomic_notifier_call_chain+0x33/0x60 [ 196.161378] power_supply_changed_work+0x84/0x110 [ 196.161394] process_one_work+0x178/0x360 [ 196.161412] ? __pfx_worker_thread+0x10/0x10 [ 196.161424] worker_thread+0x307/0x430 [ 196.161440] ? __pfx_worker_thread+0x10/0x10 [ 196.161451] kthread+0xf4/0x130 [ 196.161467] ? __pfx_kthread+0x10/0x10 [ 196.161486] ret_from_fork+0x43/0x70 [ 196.161502] ? __pfx_kthread+0x10/0x10 [ 196.161518] ret_from_fork_asm+0x1b/0x30 [ 196.161558] </TASK> [ 196.161562] ---[ end trace 0000000000000000 ]--- Since there's no guarantee that all the callbacks can work in atomic context, switch to use blocking_notifier_call_chain to relax the constraint. Signed-off-by: Kai-Heng Feng <[email protected]> Reported-by: Allen Zhong <[email protected]> Fixes: 4c71ae414474 ("platform/x86/amd/pmf: Add support SPS PMF feature") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217571 Reviewed-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tony Lindgren <[email protected]> Date: Mon Oct 23 10:48:54 2023 +0300 serial: core: Fix runtime PM handling for pending tx commit 6f699743aebf07538e506a46c5965eb8bdd2c716 upstream. Richard reported that a serial port may end up sometimes with tx data pending in the buffer for long periods of time. Turns out we bail out early on any errors from pm_runtime_get(), including -EINPROGRESS. To fix the issue, we need to ignore -EINPROGRESS as we only care about the runtime PM usage count at this point. We check for an active runtime PM state later on for tx. Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM") Cc: stable <[email protected]> Reported-by: Richard Purdie <[email protected]> Cc: Bruce Ashfield <[email protected]> Cc: Mikko Rapeli <[email protected]> Cc: Paul Gortmaker <[email protected]> Cc: Randy MacLeod <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Tested-by: Richard Purdie <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Steven Rostedt (Google) <[email protected]> Date: Sun Nov 5 10:56:31 2023 -0500 tracing: Have trace_event_file have ref counters commit bb32500fb9b78215e4ef6ee8b4345c5f5d7eafb4 upstream The following can crash the kernel: # cd /sys/kernel/tracing # echo 'p:sched schedule' > kprobe_events # exec 5>>events/kprobes/sched/enable # > kprobe_events # exec 5>&- The above commands: 1. Change directory to the tracefs directory 2. Create a kprobe event (doesn't matter what one) 3. Open bash file descriptor 5 on the enable file of the kprobe event 4. Delete the kprobe event (removes the files too) 5. Close the bash file descriptor 5 The above causes a crash! BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:tracing_release_file_tr+0xc/0x50 What happens here is that the kprobe event creates a trace_event_file "file" descriptor that represents the file in tracefs to the event. It maintains state of the event (is it enabled for the given instance?). Opening the "enable" file gets a reference to the event "file" descriptor via the open file descriptor. When the kprobe event is deleted, the file is also deleted from the tracefs system which also frees the event "file" descriptor. But as the tracefs file is still opened by user space, it will not be totally removed until the final dput() is called on it. But this is not true with the event "file" descriptor that is already freed. If the user does a write to or simply closes the file descriptor it will reference the event "file" descriptor that was just freed, causing a use-after-free bug. To solve this, add a ref count to the event "file" descriptor as well as a new flag called "FREED". The "file" will not be freed until the last reference is released. But the FREE flag will be set when the event is removed to prevent any more modifications to that event from happening, even if there's still a reference to the event "file" descriptor. Link: https://lore.kernel.org/linux-trace-kernel/[email protected]/ Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: [email protected] Cc: Mark Rutland <[email protected]> Fixes: f5ca233e2e66d ("tracing: Increase trace array ref count on enable and filter files") Reported-by: Beau Belgrave <[email protected]> Tested-by: Beau Belgrave <[email protected]> Reviewed-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cameron Williams <[email protected]> Date: Fri Oct 20 17:03:17 2023 +0100 tty: 8250: Add Brainboxes Oxford Semiconductor-based quirks commit e4876dacaca46a1b09f9b417480924ab12019a5b upstream. Some of the later revisions of the Brainboxes PX cards are based on the Oxford Semiconductor chipset. Due to the chip's unique setup these cards need to be initialised. Previously these were tested against a reference card with the same broken baudrate on another PC, cancelling out the effect. With this patch they work and can transfer/receive find against an FTDI-based device. Add all of the cards which require this setup to the quirks table. Thanks to Maciej W. Rozycki for clarification on this chip. Fixes: ef5a03a26c87 ("tty: 8250: Add support for Brainboxes PX cards.") Cc: [email protected] Signed-off-by: Cameron Williams <[email protected]> Link: https://lore.kernel.org/r/DU0PR02MB7899D222A4AB2A4E8C57108FC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cameron Williams <[email protected]> Date: Fri Oct 20 17:03:15 2023 +0100 tty: 8250: Add support for additional Brainboxes PX cards commit 9604884e592cd04ead024c9737c67a77f175cab9 upstream. Add support for some more of the Brainboxes PX (PCIe) range of serial cards, namely PX-275/PX-279, PX-475 (serial port, not LPT), PX-820, PX-803/PX-857 (additional ID). Cc: [email protected] Signed-off-by: Cameron Williams <[email protected]> Link: https://lore.kernel.org/r/DU0PR02MB78996BEC353FB346FC35444BC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cameron Williams <[email protected]> Date: Fri Oct 20 17:03:09 2023 +0100 tty: 8250: Add support for additional Brainboxes UC cards commit c563db486db7d245c0e2f319443417ae8e692f7f upstream. Add device IDs for some more Brainboxes UC cards, namely UC-235/UC-246, UC-253/UC-734, UC-302, UC-313, UC-346, UC-357, UC-607 and UC-836. Cc: [email protected] Signed-off-by: Cameron Williams <[email protected]> Link: https://lore.kernel.org/r/DU0PR02MB789969998A6C3FAFCD95C85DC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cameron Williams <[email protected]> Date: Fri Oct 20 17:03:10 2023 +0100 tty: 8250: Add support for Brainboxes UP cards commit 2c6fec1e1532f15350be7e14ba6b88a39d289fe4 upstream. Add support for the Brainboxes UP (powered PCI) range of cards, namely UP-189, UP-200, UP-869 and UP-880. Cc: [email protected] Signed-off-by: Cameron Williams <[email protected]> Link: https://lore.kernel.org/r/DU0PR02MB7899B5B59FF3D8587E88C117C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cameron Williams <[email protected]> Date: Fri Oct 20 17:03:11 2023 +0100 tty: 8250: Add support for Intashield IS-100 commit 4d994e3cf1b541ff32dfb03fbbc60eea68f9645b upstream. Add support for the Intashield IS-100 1 port serial card. Cc: [email protected] Signed-off-by: Cameron Williams <[email protected]> Link: https://lore.kernel.org/r/DU0PR02MB7899A0E0CDAA505AF5A874CDC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cameron Williams <[email protected]> Date: Fri Oct 20 17:03:16 2023 +0100 tty: 8250: Add support for Intashield IX cards commit 62d2ec2ded278c7512d91ca7bf8eb9bac46baf90 upstream. Add support for the IX-100, IX-200 and IX-400 serial cards. Cc: [email protected] Signed-off-by: Cameron Williams <[email protected]> Link: https://lore.kernel.org/r/DU0PR02MB7899614E5837E82A03272A4BC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cameron Williams <[email protected]> Date: Fri Oct 20 17:03:12 2023 +0100 tty: 8250: Fix port count of PX-257 commit d0ff5b24c2f112f29dea4c38b3bac9597b1be9ba upstream. The port count of the PX-257 Rev3 is actually 2, not 4. Fixes: ef5a03a26c87 ("tty: 8250: Add support for Brainboxes PX cards.") Cc: [email protected] Signed-off-by: Cameron Williams <[email protected]> Link: https://lore.kernel.org/r/DU0PR02MB7899C804D9F04E727B5A0E8FC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cameron Williams <[email protected]> Date: Fri Oct 20 17:03:13 2023 +0100 tty: 8250: Fix up PX-803/PX-857 commit ee61337b934c99c2611e0a945d592019b2e00c82 upstream. The PX-803/PX-857 are variants of each other, add a note. Additionally fix up the port counts for the card (2, not 1). Fixes: ef5a03a26c87 ("tty: 8250: Add support for Brainboxes PX cards.") Cc: [email protected] Signed-off-by: Cameron Williams <[email protected]> Link: https://lore.kernel.org/r/DU0PR02MB789978C8ED872FB4B014E132C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cameron Williams <[email protected]> Date: Fri Oct 20 17:03:08 2023 +0100 tty: 8250: Remove UC-257 and UC-431 commit 33092fb3af51deb80849e90a17bada44bbcde6b3 upstream. The UC-257 is a serial + LPT card, so remove it from this driver. A patch has been submitted to add it to parport_serial instead. Additionaly, the UC-431 does not use this card ID, only the UC-420 does. The 431 is a 3-port card and there is no generic 3-port configuration available, so remove reference to it from this driver. Fixes: 152d1afa834c ("tty: Add support for Brainboxes UC cards.") Cc: [email protected] Signed-off-by: Cameron Williams <[email protected]> Link: https://lore.kernel.org/r/DU0PR02MB78995ADF7394C74AD4CF3357C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daniel Starke <[email protected]> Date: Thu Oct 26 07:58:43 2023 +0200 tty: n_gsm: fix race condition in status line change on dead connections commit 3a75b205de43365f80a33b98ec9289785da56243 upstream. gsm_cleanup_mux() cleans up the gsm by closing all DLCIs, stopping all timers, removing the virtual tty devices and clearing the data queues. This procedure, however, may cause subsequent changes of the virtual modem status lines of a DLCI. More data is being added the outgoing data queue and the deleted kick timer is restarted to handle this. At this point many resources have already been removed by the cleanup procedure. Thus, a kernel panic occurs. Fix this by proving in gsm_modem_update() that the cleanup procedure has not been started and the mux is still alive. Note that writing to a virtual tty is already protected by checks against the DLCI specific connection state. Fixes: c568f7086c6e ("tty: n_gsm: fix missing timer to handle stalled links") Cc: stable <[email protected]> Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andrey Konovalov <[email protected]> Date: Thu Oct 26 22:01:12 2023 +0200 usb: raw-gadget: properly handle interrupted requests commit e8033bde451eddfb9b1bbd6e2d848c1b5c277222 upstream. Currently, if a USB request that was queued by Raw Gadget is interrupted (via a signal), wait_for_completion_interruptible returns -ERESTARTSYS. Raw Gadget then attempts to propagate this value to userspace as a return value from its ioctls. However, when -ERESTARTSYS is returned by a syscall handler, the kernel internally restarts the syscall. This doesn't allow userspace applications to interrupt requests queued by Raw Gadget (which is required when the emulated device is asked to switch altsettings). It also violates the implied interface of Raw Gadget that a single ioctl must only queue a single USB request. Instead, make Raw Gadget do what GadgetFS does: check whether the request was interrupted (dequeued with status == -ECONNRESET) and report -EINTR to userspace. Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface") Cc: stable <[email protected]> Signed-off-by: Andrey Konovalov <[email protected]> Link: https://lore.kernel.org/r/0db45b1d7cc466e3d4d1ab353f61d63c977fbbc5.1698350424.git.andreyknvl@gmail.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: LihaSika <[email protected]> Date: Fri Oct 27 20:28:04 2023 +0300 usb: storage: set 1.50 as the lower bcdDevice for older "Super Top" compatibility commit 0e3139e6543b241b3e65956a55c712333bef48ac upstream. Change lower bcdDevice value for "Super Top USB 2.0 SATA BRIDGE" to match 1.50. I have such an older device with bcdDevice=1.50 and it will not work otherwise. Cc: [email protected] Signed-off-by: Liha Sikanen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Badhri Jagan Sridharan <[email protected]> Date: Sun Oct 15 05:31:08 2023 +0000 usb: typec: tcpm: Add additional checks for contaminant commit 1a4a2df07c1f087704c24282cebe882268e38146 upstream. When transitioning from SNK_DEBOUNCED to unattached, its worthwhile to check for contaminant to mitigate wakeups. ``` [81334.219571] Start toggling [81334.228220] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [81334.305147] CC1: 0 -> 0, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] [81334.305162] state change TOGGLING -> SNK_ATTACH_WAIT [rev3 NONE_AMS] [81334.305187] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS] [81334.475515] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms] [81334.486480] CC1: 0 -> 0, CC2: 3 -> 0 [state SNK_DEBOUNCED, polarity 0, disconnected] [81334.486495] state change SNK_DEBOUNCED -> SNK_DEBOUNCED [rev3 NONE_AMS] [81334.486515] pending state change SNK_DEBOUNCED -> SNK_UNATTACHED @ 20 ms [rev3 NONE_AMS] [81334.506621] state change SNK_DEBOUNCED -> SNK_UNATTACHED [delayed 20 ms] [81334.506640] Start toggling [81334.516972] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [81334.592759] CC1: 0 -> 0, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] [81334.592773] state change TOGGLING -> SNK_ATTACH_WAIT [rev3 NONE_AMS] [81334.592792] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS] [81334.762940] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms] [81334.773557] CC1: 0 -> 0, CC2: 3 -> 0 [state SNK_DEBOUNCED, polarity 0, disconnected] [81334.773570] state change SNK_DEBOUNCED -> SNK_DEBOUNCED [rev3 NONE_AMS] [81334.773588] pending state change SNK_DEBOUNCED -> SNK_UNATTACHED @ 20 ms [rev3 NONE_AMS] [81334.793672] state change SNK_DEBOUNCED -> SNK_UNATTACHED [delayed 20 ms] [81334.793681] Start toggling [81334.801840] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [81334.878655] CC1: 0 -> 0, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] [81334.878672] state change TOGGLING -> SNK_ATTACH_WAIT [rev3 NONE_AMS] [81334.878696] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS] [81335.048968] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms] [81335.060684] CC1: 0 -> 0, CC2: 3 -> 0 [state SNK_DEBOUNCED, polarity 0, disconnected] [81335.060754] state change SNK_DEBOUNCED -> SNK_DEBOUNCED [rev3 NONE_AMS] [81335.060775] pending state change SNK_DEBOUNCED -> SNK_UNATTACHED @ 20 ms [rev3 NONE_AMS] [81335.080884] state change SNK_DEBOUNCED -> SNK_UNATTACHED [delayed 20 ms] [81335.080900] Start toggling ``` Cc: [email protected] Fixes: 599f008c257d ("usb: typec: tcpm: Add callbacks to mitigate wakeups due to contaminant") Signed-off-by: Badhri Jagan Sridharan <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jimmy Hu <[email protected]> Date: Fri Oct 20 01:21:32 2023 +0000 usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm() commit 4987daf86c152ff882d51572d154ad12e4ff3a4b upstream. It is possible that typec_register_partner() returns ERR_PTR on failure. When port->partner is an error, a NULL pointer dereference may occur as shown below. [91222.095236][ T319] typec port0: failed to register partner (-17) ... [91225.061491][ T319] Unable to handle kernel NULL pointer dereference at virtual address 000000000000039f [91225.274642][ T319] pc : tcpm_pd_data_request+0x310/0x13fc [91225.274646][ T319] lr : tcpm_pd_data_request+0x298/0x13fc [91225.308067][ T319] Call trace: [91225.308070][ T319] tcpm_pd_data_request+0x310/0x13fc [91225.308073][ T319] tcpm_pd_rx_handler+0x100/0x9e8 [91225.355900][ T319] kthread_worker_fn+0x178/0x58c [91225.355902][ T319] kthread+0x150/0x200 [91225.355905][ T319] ret_from_fork+0x10/0x30 Add a check for port->partner to avoid dereferencing a NULL pointer. Fixes: 5e1d4c49fbc8 ("usb: typec: tcpm: Determine common SVDM Version") Cc: [email protected] Signed-off-by: Jimmy Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>