FROMLIST: PCI: qcom: Add .get_ltssm() helper#724
Open
krishnachaitanya-linux wants to merge 1321 commits intoqualcomm-linux:tech/bus/pci/allfrom
Open
FROMLIST: PCI: qcom: Add .get_ltssm() helper#724krishnachaitanya-linux wants to merge 1321 commits intoqualcomm-linux:tech/bus/pci/allfrom
krishnachaitanya-linux wants to merge 1321 commits intoqualcomm-linux:tech/bus/pci/allfrom
Conversation
The last rtg should be able to grow when the size of the last is less than (and not equal to) sb_rgextents. xfs_growfs with realtime groups fails without this patch. The reason is that, xfs_growfs_rtg() tries to grow the last rt group even when the last rt group is at its maximal size i.e, sb_rgextents. It fails with the following messages: XFS (loop0): Internal error block >= mp->m_rsumblocks at line 253 of file fs/xfs/libxfs/xfs_rtbitmap.c. Caller xfs_rtsummary_read_buf+0x20/0x80 XFS (loop0): Corruption detected. Unmount and run xfs_repair XFS (loop0): Internal error xfs_trans_cancel at line 976 of file fs/xfs/xfs_trans.c. Caller xfs_growfs_rt_bmblock+0x402/0x450 XFS (loop0): Corruption of in-memory data (0x8) detected at xfs_trans_cancel+0x10a/0x1f0 (fs/xfs/xfs_trans.c:977). Shutting down filesystem. XFS (loop0): Please unmount the filesystem and rectify the problem(s) Signed-off-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Sparse inode cluster allocation sets min/max agbno values to avoid allocating an inode cluster that might map to an invalid inode chunk. For example, we can't have an inode record mapped to agbno 0 or that extends past the end of a runt AG of misaligned size. The initial calculation of max_agbno is unnecessarily conservative, however. This has triggered a corner case allocation failure where a small runt AG (i.e. 2063 blocks) is mostly full save for an extent to the EOFS boundary: [2050,13]. max_agbno is set to 2048 in this case, which happens to be the offset of the last possible valid inode chunk in the AG. In practice, we should be able to allocate the 4-block cluster at agbno 2052 to map to the parent inode record at agbno 2048, but the max_agbno value precludes it. Note that this can result in filesystem shutdown via dirty trans cancel on stable kernels prior to commit 9eb7759 ("xfs: walk all AGs if TRYLOCK passed to xfs_alloc_vextent_iterate_ags") because the tail AG selection by the allocator sets t_highest_agno on the transaction. If the inode allocator spins around and finds an inode chunk with free inodes in an earlier AG, the subsequent dir name creation path may still fail to allocate due to the AG restriction and cancel. To avoid this problem, update the max_agbno calculation to the agbno prior to the last chunk aligned agbno in the AG. This is not necessarily the last valid allocation target for a sparse chunk, but since inode chunks (i.e. records) are chunk aligned and sparse allocs are cluster sized/aligned, this allows the sb_spino_align alignment restriction to take over and round down the max effective agbno to within the last valid inode chunk in the AG. Note that even though the allocator improvements in the aforementioned commit seem to avoid this particular dirty trans cancel situation, the max_agbno logic improvement still applies as we should be able to allocate from an AG that has been appropriately selected. The more important target for this patch however are older/stable kernels prior to this allocator rework/improvement. Cc: stable@vger.kernel.org # v4.2 Fixes: 56d1115 ("xfs: allocate sparse inode chunks on full chunk allocation failure") Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
The commit d5d399e ("printk/nbcon: Release nbcon consoles ownership in atomic flush after each emitted record") prevented stall of a CPU which lost nbcon console ownership because another CPU entered an emergency flush. But there is still the problem that the CPU doing the emergency flush might cause a stall on its own. Let's go even further and restore IRQ in the atomic flush after each emitted record. It is not a complete solution. The interrupts and/or scheduling might still be blocked when the emergency atomic flush was called with IRQs and/or scheduling disabled. But it should remove the following lockup: mlx5_core 0000:03:00.0: Shutdown was called kvm: exiting hardware virtualization arm-smmu-v3 arm-smmu-v3.10.auto: CMD_SYNC timeout at 0x00000103 [hwprod 0x00000104, hwcons 0x00000102] smp: csd: Detected non-responsive CSD lock (qualcomm-linux#1) on CPU#4, waiting 5000000032 ns for CPU#00 do_nothing (kernel/smp.c:1057) smp: csd: CSD lock (qualcomm-linux#1) unresponsive. [...] Call trace: pl011_console_write_atomic (./arch/arm64/include/asm/vdso/processor.h:12 drivers/tty/serial/amba-pl011.c:2540) (P) nbcon_emit_next_record (kernel/printk/nbcon.c:1049) __nbcon_atomic_flush_pending_con (kernel/printk/nbcon.c:1517) __nbcon_atomic_flush_pending.llvm.15488114865160659019 (./arch/arm64/include/asm/alternative-macros.h:254 ./arch/arm64/include/asm/cpufeature.h:808 ./arch/arm64/include/asm/irqflags.h:192 kernel/printk/nbcon.c:1562 kernel/printk/nbcon.c:1612) nbcon_atomic_flush_pending (kernel/printk/nbcon.c:1629) printk_kthreads_shutdown (kernel/printk/printk.c:?) syscore_shutdown (drivers/base/syscore.c:120) kernel_kexec (kernel/kexec_core.c:1045) __arm64_sys_reboot (kernel/reboot.c:794 kernel/reboot.c:722 kernel/reboot.c:722) invoke_syscall (arch/arm64/kernel/syscall.c:50) el0_svc_common.llvm.14158405452757855239 (arch/arm64/kernel/syscall.c:?) do_el0_svc (arch/arm64/kernel/syscall.c:152) el0_svc (./arch/arm64/include/asm/alternative-macros.h:254 ./arch/arm64/include/asm/cpufeature.h:808 ./arch/arm64/include/asm/irqflags.h:73 arch/arm64/kernel/entry-common.c:169 arch/arm64/kernel/entry-common.c:182 arch/arm64/kernel/entry-common.c:749) el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:820) el0t_64_sync (arch/arm64/kernel/entry.S:600) In this case, nbcon_atomic_flush_pending() is called from printk_kthreads_shutdown() with IRQs and scheduling enabled. Note that __nbcon_atomic_flush_pending_con() is directly called also from nbcon_device_release() where the disabled IRQs might break PREEMPT_RT guarantees. But the atomic flush is called only in emergency or panic situations where the latencies are irrelevant anyway. An ultimate solution would be a touching of watchdogs. But it would hide all problems. Let's do it later when anyone reports a stall which does not have a better solution. Closes: https://lore.kernel.org/r/sqwajvt7utnt463tzxgwu2yctyn5m6bjwrslsnupfexeml6hkd@v6sqmpbu3vvu Tested-by: Breno Leitao <leitao@debian.org> Reviewed-by: John Ogness <john.ogness@linutronix.de> Link: https://patch.msgid.link/20251212124520.244483-1-pmladek@suse.com Signed-off-by: Petr Mladek <pmladek@suse.com>
It's strongly recommended for GPIO drivers to always implement the .get_direction() callback - even for fixed-direction controllers. GPIO core will even emit a warning if the callback is missing, when users try to read the direction of a pin. Implement .get_direction() for gpio-davinci. Reported-by: Michael Walle <mwalle@kernel.org> Closes: https://lore.kernel.org/all/DFJAFK3DTBOZ.3G2P3A5IH34GF@kernel.org/ Reviewed-by: Linus Walleij <linusw@kernel.org> Fixes: a060b8c ("gpiolib: implement low-level, shared GPIO support") Tested-by: Michael Walle <mwalle@kernel.org> # on sa67 Link: https://lore.kernel.org/r/20260109130832.27326-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
The presence of the .get_direction() callback is already checked in gpiochip_get_direction(). Remove the duplicated check which also returns the wrong error code to user-space. Fixes: e623c43 ("gpiolib: sanitize the return value of gpio_chip::get_direction()") Reported-by: Michael Walle <mwalle@kernel.org> Closes: https://lore.kernel.org/all/DFJAFK3DTBOZ.3G2P3A5IH34GF@kernel.org/ Link: https://lore.kernel.org/r/20260109105557.20024-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Handle the error code from snd_pcm_buffer_access_lock() in snd_pcm_runtime_buffer_set_silence() function. Found by Alexandros Panagiotou <apanagio@redhat.com> Fixes: 93a81ca ("ALSA: pcm: Fix race of buffer access at PCM OSS layer") Cc: stable@vger.kernel.org # 6.15 Signed-off-by: Jaroslav Kysela <perex@perex.cz> Link: https://patch.msgid.link/20260107213642.332954-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
There is currently an issue with UEFI calibration data parsing for some TAS devices, like the ASUS ROG Xbox Ally X (RC73XA), that causes audio quality issues such as gaps in playback. Until the issue is root caused and fixed, add a quirk to skip using the UEFI calibration data and fall back to using the calibration data provided by the DSP firmware, which restores full speaker functionality on affected devices. Cc: stable@vger.kernel.org # 6.18 Link: https://lore.kernel.org/all/160aef32646c4d5498cbfd624fd683cc@ti.com/ Closes: https://lore.kernel.org/all/0ba100d0-9b6f-4a3b-bffa-61abe1b46cd5@linux.dev/ Suggested-by: Baojun Xu <baojun.xu@ti.com> Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev> Reviewed-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://patch.msgid.link/20260108093650.1142176-1-matthew.schwartz@linux.dev Signed-off-by: Takashi Iwai <tiwai@suse.de>
…, fix speakers Just like GA403U, this GA403W needs to remap woofers to DAC1. Similarly to other Asus devices, headphones/headset MIC is not working, however the pin config alone is not enough to fix it. From Windows dump of GA403W: 0x12, 0x90a60140 # Correctly set by codec out of the box 0x13, 0x90a60550 0x14, 0x90170510 0x17, 0x90170120 # Correctly set by codec out of the box 0x19, 0x03a11050 # Set by ALC285_FIXUP_ASUS_GA403U_HEADSET_MIC 0x1a, 0x411115F0 0x1b, 0x03a11c30 # Set by ALC285_FIXUP_ASUS_GA403U_HEADSET_MIC 0x1d, 0x40663A45 # Correctly set by codec out of the box 0x21, 0x03211430 Even with all the values set, MIC of the jack is not detected. Until a complete solution is found, set ALC285_FIXUP_ASUS_GA403U_HEADSET_MIC for GA403W which fixes audio volume control for woofers. No need to create new quirk with missing pin config just yet, since its not making the situation better. Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com> Link: https://patch.msgid.link/20260112-asus-rog-audio-v1-1-513957b4704e@vinarskis.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
Set gpiochip parent to the struct device of the dummy GPIO driver so that the software node will be associated with the GPIO chip. The recent commit e5d527b ("gpio: swnode: don't use the swnode's name as the key for GPIO lookup") broke cirrus_scodec_test, because the software node no longer gets associated with the GPIO driver by name. Instead, setting struct gpio_chip.parent to the owning struct device will find the node using a normal fwnode lookup. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 2144833 ("ALSA: hda: cirrus_scodec: Add KUnit test") Link: https://patch.msgid.link/20260113130954.574670-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
Change the test suite name string to "snd-hda-cirrus-scodec-test". It was incorrectly named "snd-hda-scodec-cs35l56-test", a leftover from when the code under test was actually in the cs35l56 driver. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 2144833 ("ALSA: hda: cirrus_scodec: Add KUnit test") Link: https://patch.msgid.link/20260113134056.619051-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
In this case, the user constructed the parameters with maxpacksize 40 for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer size for each data URB is maxpacksize * packets, which in this example is 40 * 6 = 240; When the user performs a write operation to send audio data into the ALSA PCM playback stream, the calculated number of frames is packsize[0] * packets = 264, which exceeds the allocated URB buffer size, triggering the out-of-bounds (OOB) issue reported by syzbot [1]. Added a check for the number of single data URB frames when calculating the number of frames to prevent [1]. [1] BUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506 Call Trace: copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611 prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333 Reported-by: syzbot+6db0415d6d5c635f72cb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6db0415d6d5c635f72cb Tested-by: syzbot+6db0415d6d5c635f72cb@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis@qq.com> Link: https://patch.msgid.link/tencent_9AECE6CD2C7A826D902D696C289724E8120A@qq.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
This quirk enables mute LED on HP Pavilion x360 2-in-1 Laptop 14-ek0xxx, which use ALC245 codec. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220220 Cc: <stable@vger.kernel.org> Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260115015844.3129890-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add missing quirks for some new Dell laptops using cs42l43's speaker outputs. Signed-off-by: Deep Harsora <Deep_Harsora@dell.com> Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com> Link: https://patch.msgid.link/20260102152132.3053106-1-mstrozek@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Even the device node don't exist, the graph_util_parse_link_direction() will overwrite the playback_only and capture_only to be zero. Which cause the playback_only and capture_only are not correct, so check device node exist or not before update the value. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/20251229090432.3964848-1-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
The Everest ES8316 has interrupt capability on its GPIO3 pin for headphone detection. Several of the RockPi 4 variants are using it already. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260105193203.3166320-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
The soundwire update_status() callback may be called multiple times with the same ATTACHED status but initialisation should only be done when transitioning from UNATTACHED to ATTACHED. This avoids repeated initialisation of the codecs during boot of machines like the Lenovo ThinkPad X13s: [ 11.614523] wsa883x-codec sdw:1:0:0217:0202:00:1: WSA883X Version 1_1, Variant: WSA8835_V2 [ 11.618022] wsa883x-codec sdw:1:0:0217:0202:00:1: WSA883X Version 1_1, Variant: WSA8835_V2 [ 11.621377] wsa883x-codec sdw:1:0:0217:0202:00:1: WSA883X Version 1_1, Variant: WSA8835_V2 [ 11.624065] wsa883x-codec sdw:1:0:0217:0202:00:1: WSA883X Version 1_1, Variant: WSA8835_V2 [ 11.631382] wsa883x-codec sdw:1:0:0217:0202:00:2: WSA883X Version 1_1, Variant: WSA8835_V2 [ 11.634424] wsa883x-codec sdw:1:0:0217:0202:00:2: WSA883X Version 1_1, Variant: WSA8835_V2 Fixes: 43b8c7d ("ASoC: codecs: add wsa883x amplifier support") Cc: stable@vger.kernel.org # 6.0 Cc: Srinivas Kandagatla <srini@kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260102111413.9605-2-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
The soundwire update_status() callback may be called multiple times with the same ATTACHED status but initialisation should only be done when transitioning from UNATTACHED to ATTACHED. Fixes: a0aab9e ("ASoC: codecs: add wsa881x amplifier support") Cc: stable@vger.kernel.org # 5.6 Cc: Srinivas Kandagatla <srini@kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260102111413.9605-3-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
The soundwire update_status() callback may be called multiple times with the same ATTACHED status but initialisation should only be done when transitioning from UNATTACHED to ATTACHED. Fix the inverted hw_init flag which was set to false instead of true after initialisation which defeats its purpose and may result in repeated unnecessary initialisation. Similarly, the initial state of the flag was also inverted so that the codec would only be initialised and brought out of regmap cache only mode if its status first transitions to UNATTACHED. Fixes: aa21a7d ("ASoC: codecs: wsa884x: Add WSA884x family of speakers") Cc: stable@vger.kernel.org # 6.5 Cc: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Tested-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260102111413.9605-4-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
Drivers should generally be silent on successful probe. Demote the codec variant printk to debug level and instead add a warning in case an unknown variant is ever encountered. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260102111413.9605-5-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
If manipulating big-endian data, make the pointers be big-endian instead of host-endian. This should stop the following sparse warnigns about endian-conversion: sound/soc/soc-ops.c:547:33: warning: invalid assignment: &= sound/soc/soc-ops.c:547:33: left side has type unsigned short sound/soc/soc-ops.c:547:33: right side has type restricted __be16 sound/soc/soc-ops.c:551:33: warning: invalid assignment: &= sound/soc/soc-ops.c:551:33: left side has type unsigned int sound/soc/soc-ops.c:551:33: right side has type restricted __be32 Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Link: https://patch.msgid.link/20260106225846.83580-1-ben.dooks@codethink.co.uk Signed-off-by: Mark Brown <broonie@kernel.org>
The davinci_evm_probe() function calls of_parse_phandle() to acquire device nodes for "ti,audio-codec" and "ti,mcasp-controller". These functions return device nodes with incremented reference counts. However, in several error paths (e.g., when the second of_parse_phandle(), snd_soc_of_parse_card_name(), or devm_snd_soc_register_card() fails), the function returns directly without releasing the acquired nodes, leading to reference leaks. This patch adds an error handling path 'err_put' to properly release the device nodes using of_node_put() and clean up the pointers when an error occurs. Signed-off-by: Kery Qi <qikeyu2017@gmail.com> Link: https://patch.msgid.link/20260107154836.1521-2-qikeyu2017@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
The RT5640 has an MCLK pin and several users already define a clocks entry. A 'port' node is also in use and a common node for codecs. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260108215307.1138515-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
…urce The driver accepts and uses a value of 7 for realtek,jack-detect-source. What exactly it means isn't clear though. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260108215307.1138515-2-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
Add a "port" node entry for Rockchip S/PDIF binding. It's already in use and a common property for DAIs. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260108224938.1320809-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
…210_ahub Commit 4d4021b ("ASoC: tegra: Fix uninitialized flat cache warning in tegra210_ahub") attempted to fix the uninitialized flat cache warning that is observed for the Tegra210 AHUB driver. However, the change broke various audio tests because an -EBUSY error is returned when accessing registers from cache before they are read from hardware. Revert this change for now, until a proper fix is available. Fixes: 4d4021b ("ASoC: tegra: Fix uninitialized flat cache warning in tegra210_ahub") Signed-off-by: sheetal <sheetal@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20251217132524.2844499-1-sheetal@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
Add DMI match for ASUSTeK COMPUTER INC. M6500RE to enable the internal microphone. Signed-off-by: Radhi Bajahaw <bajahawradhi@gmail.com> Link: https://patch.msgid.link/20260112203814.155-1-bajahawradhi@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Commit eba5a0b ("ASoC: dt-bindings: realtek,rt5640: Convert to dtschema") converted the rt5640 dt-binding to yaml format but in the process dropped 'clock' and 'clock-names' properties that are used to specify the codec 'mclk'. This is causing DTB build warnings for boards that use this codec and define an 'mclk' in device-tree. Update the rt5640 binding document to add the optional mclk. Fixes: eba5a0b ("ASoC: dt-bindings: realtek,rt5640: Convert to dtschema") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260108143158.351223-2-jonathanh@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
The device-tree property 'realtek,jack-detect-source' currently only permits values from 0-6. However, commit 2b9c8d2 ("ASoC: rt5640: Add the HDA header support") updated the Realtek rt5640 to support setting the 'realtek,jack-detect-source' to 7 to support the HDA header. The Tegra234 platforms currently set 'realtek,jack-detect-source' to 7 for the HDA header and this is causing a warning when building device-tree. audio-codec@1c (realtek,rt5640): realtek,jack-detect-source: 7 is not one of [0, 1, 2, 3, 4, 5, 6] Given that the driver already supports this settings, update the binding document for the rt5640 device to add the HDA header as a valid configuration for the 'realtek,jack-detect-source' property. Fixes: 2b9c8d2 ("ASoC: rt5640: Add the HDA header support") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260108143158.351223-3-jonathanh@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
Various boards that use the rt5640 audio codec define a 'port' child node under the codec node to describe the interface between it and the SoC that it is connected to. The binding document for the rt5640 codec does not define the 'port' child node and so this is generating warnings when running the DTB checks for these boards. Add the 'port' node to the binding document for the rt5640 codec to fix this. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260108143158.351223-4-jonathanh@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
The CS42L43 codec's load detection can return different impedance values that map to either HEADPHONE or LINEOUT jack types. However, the soc_jack_pins array only maps SND_JACK_HEADPHONE to the "Headphone" DAPM pin, not SND_JACK_LINEOUT. When headphones are detected with an impedance that maps to LINEOUT (such as impedance value 0x2), the driver reports SND_JACK_LINEOUT. Since this doesn't match the jack pin mask, the "Headphone" DAPM pin is not activated, and no audio is routed to the headphone outputs. Fix by adding SND_JACK_LINEOUT to the Headphone pin mask, so that both headphone and line-out detection properly enable the headphone output path. This fixes no audio output on devices like the Lenovo ThinkPad P16 Gen 3 where headphones are detected with LINEOUT impedance. Fixes: d74bad3 ("ASoC: intel: sof_sdw_cs42l43: Create separate jacks for hp and mic") Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Cole Leavitt <cole@unwrap.rs> Link: https://patch.msgid.link/20260114025518.28519-1-cole@unwrap.rs Signed-off-by: Mark Brown <broonie@kernel.org>
…en4 2-lanes PHY The fourth and sixth PCIe instances on Glymur are both Gen4 2-lane PHY. So document the compatible. Link: https://lore.kernel.org/r/20251224-phy-qcom-pcie-add-glymur-v3-1-57396145bc22@oss.qualcomm.com Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Glymur platform has two Gen4 2-lanes controllers, the fourth and sixth instances. Add support for their PHYs. Link: https://lore.kernel.org/r/20251224-phy-qcom-pcie-add-glymur-v3-2-57396145bc22@oss.qualcomm.com Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
On the Qualcomm Glymur platform the PCIe host is compatible with the DWC controller present on the X1E80100 platform. So document the PCIe controllers found on Glymur and use the X1E80100 compatible string as a fallback in the schema. Link: https://lore.kernel.org/all/20251017-glymur_pcie-v5-3-82d0c4bd402b@oss.qualcomm.com/ Signed-off-by: Prudhvi Yarlagadda <quic_pyarlaga@quicinc.com> Signed-off-by: Wenbin Yao <wenbin.yao@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
… compatible Document compatible for the QMP PCIe PHY on Kaanapali platform. Link: https://lore.kernel.org/all/20251124-kaanapali-pcie-phy-v4-1-d04ee9cca83b@oss.qualcomm.com/ Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
…egister offsets Kaanapali SoC uses QMP PHY with version v8 for PCIe Gen3 x2, but requires a completely unique qserdes-txrx register offsets compared to existing v8 offsets. Hence, add a dedicated header file containing the FULL SET of qserdes-txrx register definitions required for Kaanapali's PCIe PHY operation. Link:https://lore.kernel.org/all/20251124-kaanapali-pcie-phy-v4-2-d04ee9cca83b@oss.qualcomm.com/ Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Kaanapali SoC uses QMP phy with version v8 for PCIe Gen3 x2. Add the new PCS PCIE specific offsets in a dedicated header file. Link: https://lore.kernel.org/all/20251124-kaanapali-pcie-phy-v4-3-d04ee9cca83b@oss.qualcomm.com/ Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Some qserdes-com register offsets for the v8 PHY were previously omitted, as they were not needed by earlier v8 PHY initialization sequences. Add these missing v8 register offsets now required to support PCIe QMP PHY on Kaanapali platform. Link: https://lore.kernel.org/all/20251124-kaanapali-pcie-phy-v4-4-d04ee9cca83b@oss.qualcomm.com/ Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Add QMP PCIe PHY support for the Kaanapali platform. Link: https://lore.kernel.org/r/20251124-kaanapali-pcie-phy-v4-5-d04ee9cca83b@oss.qualcomm.com Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Previously, the driver skipped putting the link into L2/device state in D3cold whenever L1 ASPM was enabled, since some devices (e.g. NVMe) expect low resume latency and may not tolerate deeper power states. However, such devices typically remain in D0 and are already covered by the new helper's requirement that all endpoints be in D3hot before the host bridge may enter D3cold. So, replace the local L1/L1SS-based check in dw_pcie_suspend_noirq() with the shared pci_host_common_can_enter_d3cold() helper to decide whether the DesignWare host bridge can safely transition to D3cold. Link: https://lore.kernel.org/r/20260128-d3cold-v1-2-dd8f3f0ce824@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
…host bridges Add a common helper, pci_host_common_can_enter_d3cold(), to determine whether a PCI host bridge can safely transition to D3cold. The helper walks all devices on the bridge's bus and only allows the host bridge to enter D3cold if all PCIe endpoints are already in PCI_D3hot. For devices that may wake the system, it additionally requires that the device supports PME wakeup from D3cold(with WAKE#). Devices without wakeup enabled are not restricted by this check and can be allowed to keep device in D3cold. Link: https://lore.kernel.org/r/20260128-d3cold-v1-1-dd8f3f0ce824@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Add pme_turn_off() support and use DWC common suspend resume methods for device D3cold entry & exit. If the device is not kept in D3cold use existing methods like keeping icc votes, opp votes etc.. intact. In qcom_pcie_deinit_2_7_0(), explicitly disable PCIe clocks and resets in the controller. Remove suspended flag from qcom_pcie structure as it is no longer needed. Link: https://lore.kernel.org/r/20260128-d3cold-v1-3-dd8f3f0ce824@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Currently, the driver expects the devices to remain in D0 across system suspend, but the genpd framework may still power down the associated GDSC during suspend. When that happens, the PCIe link goes down and cannot be recovered on resume. Prevent genpd from turning off the PCIe GDSC by using dev_pm_genpd_rpm_always_on() so that the power domain stays on while the controller is suspended. This preserves the link state across suspend/resume and avoids unrecoverable link failures. Fixes: 82a8238 ("PCI: qcom: Add Qualcomm PCIe controller driver") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260128-genpd_fix-v1-1-cd45a249d12f@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
… consistency
Previously the pwrseq, tc9563, and slot pwrctrl drivers used different
naming conventions for their private data structs and pointers to them,
which makes patches hard to read:
Previous names New names
------------------------------------ ----------------------------------
struct pci_pwrctrl_pwrseq_data { struct pci_pwrctrl_pwrseq {
struct pci_pwrctrl ctx; struct pci_pwrctrl pwrctrl;
struct pci_pwrctrl_pwrseq_data *data struct pci_pwrctrl_pwrseq *pwrseq
struct tc9563_pwrctrl_ctx { struct pci_pwrctrl_tc9563 {
struct tc9563_pwrctrl_ctx *ctx struct pci_pwrctrl_tc9563 *tc9563
struct pci_pwrctrl_slot_data { struct pci_pwrctrl_slot {
struct pci_pwrctrl ctx; struct pci_pwrctrl pwrctrl;
struct pci_pwrctrl_slot_data *slot struct pci_pwrctrl_slot *slot
Rename "struct pci_pwrctrl_pwrseq_data" to "pci_pwrctrl_pwrseq".
Rename the "struct pci_pwrctrl ctx" member to "struct pci_pwrctrl pwrctrl".
Rename pointers from "struct pci_pwrctrl_pwrseq_data *data" to
"struct pci_pwrctrl_pwrseq *pwrseq".
No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-1-9d26da3ce903@oss.qualcomm.com
…onsistency
Previously the pwrseq, tc9563, and slot pwrctrl drivers used different
naming conventions for their private data structs and pointers to them,
which makes patches hard to read:
Previous names New names
------------------------------------ ----------------------------------
struct pci_pwrctrl_pwrseq_data { struct pci_pwrctrl_pwrseq {
struct pci_pwrctrl ctx; struct pci_pwrctrl pwrctrl;
struct pci_pwrctrl_pwrseq_data *data struct pci_pwrctrl_pwrseq *pwrseq
struct tc9563_pwrctrl_ctx { struct pci_pwrctrl_tc9563 {
struct tc9563_pwrctrl_ctx *ctx struct pci_pwrctrl_tc9563 *tc9563
struct pci_pwrctrl_slot_data { struct pci_pwrctrl_slot {
struct pci_pwrctrl ctx; struct pci_pwrctrl pwrctrl;
struct pci_pwrctrl_slot_data *slot struct pci_pwrctrl_slot *slot
Rename "struct pci_pwrctrl_slot_data" to "struct pci_pwrctrl_slot".
Rename the "struct pci_pwrctrl ctx" member to "struct pci_pwrctrl pwrctrl".
No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-2-9d26da3ce903@oss.qualcomm.com
…apter() The API comment for of_find_i2c_adapter_by_node() recommends using put_device() to drop the reference count of I2C adapter instead of using i2c_put_adapter(). So replace i2c_put_adapter() with put_device(). Fixes: 4c9c7be ("PCI: pwrctrl: Add power control driver for TC9563") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-3-9d26da3ce903@oss.qualcomm.com
Most of pci-pwrctrl-tc9563.c fits in 80 columns. Wrap lines that are gratuitously longer. Whitespace changes only. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-4-9d26da3ce903@oss.qualcomm.com
Add local struct device * and struct device_node * variables to reduce repetitive pointer chasing. No functional changes intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-5-9d26da3ce903@oss.qualcomm.com
… consistency
Previously the pwrseq, tc9563, and slot pwrctrl drivers used different
naming conventions for their private data structs and pointers to them,
which makes patches hard to read:
Previous names New names
------------------------------------ ----------------------------------
struct pci_pwrctrl_pwrseq_data { struct pci_pwrctrl_pwrseq {
struct pci_pwrctrl ctx; struct pci_pwrctrl pwrctrl;
struct pci_pwrctrl_pwrseq_data *data struct pci_pwrctrl_pwrseq *pwrseq
struct tc9563_pwrctrl_ctx { struct pci_pwrctrl_tc9563 {
struct tc9563_pwrctrl_ctx *ctx struct pci_pwrctrl_tc9563 *tc9563
struct pci_pwrctrl_slot_data { struct pci_pwrctrl_slot {
struct pci_pwrctrl ctx; struct pci_pwrctrl pwrctrl;
struct pci_pwrctrl_slot_data *slot struct pci_pwrctrl_slot *slot
Rename "struct tc9563_pwrctrl_ctx" to "pci_pwrctrl_tc9563".
Move the struct pci_pwrctrl member to be the first element in struct
pci_pwrctrl_tc9563, as it is in the other drivers.
Rename pointers from "struct tc9563_pwrctrl_ctx *ctx" to
"struct pci_pwrctrl_tc9563 *tc9563".
No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-6-9d26da3ce903@oss.qualcomm.com
In order to allow the pwrctrl core to control the power on/off logic of the
pwrctrl slot driver, move the power on/off code to
pci_pwrctrl_slot_power_{off/on} helper functions.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-7-9d26da3ce903@oss.qualcomm.com
In order to allow the pwrctrl core to control the power on/off logic of the
pwrctrl pwrseq driver, move the power on/off code to
pci_pwrctrl_pwrseq_power_{off/on} helper functions.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-8-9d26da3ce903@oss.qualcomm.com
…acks
To allow the pwrctrl core to control the power on/off sequences of the
pwrctrl drivers, add the 'struct pci_pwrctrl::power_{on/off}' callbacks and
populate them in the respective pwrctrl drivers.
The pwrctrl drivers still power on the resources on their own now. So there
is no functional change.
Co-developed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-9-9d26da3ce903@oss.qualcomm.com
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Previously, the PCI core created pwrctrl devices during pci_scan_device() on its own and then skipped enumeration of those devices, hoping the pwrctrl driver would power them on and trigger a bus rescan. This approach works for endpoint devices directly connected to Root Ports, but it fails for PCIe switches acting as bus extenders. When the switch requires pwrctrl support and the pwrctrl driver is not available during the pwrctrl device creation, its enumeration will be skipped during the initial PCI bus scan. This premature scan leads the PCI core to allocate resources (bridge windows, bus numbers) for the upstream bridge based on available downstream buses at scan time. For non-hotplug capable bridges, PCI core typically allocates resources based on the number of buses available during the initial bus scan, which happens to be just one if the switch is not powered on and enumerated at that time. When the switch gets enumerated later on, it will fail due to the lack of upstream resources. As a result, a PCIe switch powered on by the pwrctrl driver cannot be reliably enumerated currently. Either the switch has to be enabled in the bootloader or the switch pwrctrl driver has to be loaded during the pwrctrl device creation time to work around these issues. Introduce new APIs to explicitly create and destroy pwrctrl devices from controller drivers by recursively scanning the PCI child nodes of the controller. These APIs allow creating pwrctrl devices based on the original criteria and are intended to be called during controller probe and removal. These APIs, together with the upcoming APIs for power on/off will allow the controller drivers to power on all the devices before starting the initial bus scan, thereby solving the resource allocation issue. Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-10-9d26da3ce903@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
To fix bridge resource allocation issues when powering PCI bridges with the
pwrctrl driver, introduce APIs to explicitly power on and off all related
devices simultaneously.
Previously, the individual pwrctrl drivers powered on/off the PCI devices
autonomously, without any control from the controller drivers. But to
enforce ordering with respect to powering on the devices, these APIs will
power on/off all the devices at the same time.
The pci_pwrctrl_power_on_devices() API recursively scans the PCI child
nodes, makes sure that pwrctrl drivers are bound to devices, and calls
their power_on() callbacks. If any pwrctrl driver is not bound, it will
return -EPROBE_DEFER.
Similarly, pci_pwrctrl_power_off_devices() API powers off devices
recursively via their power_off() callbacks.
These APIs are expected to be called during the controller probe and
suspend/resume time to power on/off the devices. But before calling these
APIs, the pwrctrl devices should be created using the
pci_pwrctrl_{create/destroy}_devices() APIs.
Co-developed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
[bhelgaas: return early when !pdev and unindent, move ctx.power_on/off here]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-11-9d26da3ce903@oss.qualcomm.com
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
…y APIs Adopt pwrctrl APIs to create, power on/off, and destroy pwrctrl devices. In qcom_pcie_host_init(), call pci_pwrctrl_create_devices() to create devices, then pci_pwrctrl_power_on_devices() to power them on, both after controller resource initialization. Once successful, deassert PERST# for all devices. In qcom_pcie_host_deinit(), call pci_pwrctrl_power_off_devices() after asserting PERST#. Note that pci_pwrctrl_destroy_devices() is not called here, as deinit is only invoked during system suspend where device destruction is unnecessary. If the driver becomes removable in future, pci_pwrctrl_destroy_devices() should be called in the remove() handler. Remove the old pwrctrl framework code from the PCI core (including devlinks) as the new APIs are now the sole consumer of pwrctrl functionality. And also do not power on the pwrctrl drivers during probe() as this is now handled by the APIs. Co-developed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-12-9d26da3ce903@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Previously, the pcie-qcom driver probed first, deasserted PERST#, enabled link training and scanned the bus. By the time the pwrctrl driver probe got called, link training was already enabled by the controller driver. Thus the pwrctrl drivers had to call the .assert_perst() callback, to assert PERST#, power on the needed resources, and then call the .assert_perst() callback to deassert PERST#. Now since all pwrctrl drivers and this controller driver have been converted to the new pwrctrl design where the pwrctrl drivers will first power on the devices before this driver deasserts PERST# and scan the bus. So there is no longer a need for .assert_perst() callback in this driver and in DWC core driver. Hence, drop them. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-13-9d26da3ce903@oss.qualcomm.com
Now since all .assert_callback() implementations have been removed from the controller drivers, drop the .assert_callback callback from pci.h. Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-14-9d26da3ce903@oss.qualcomm.com
…mity
Rename the PERST# assert/deassert helpers from
qcom_ep_reset_{assert/deassert}() to qcom_pcie_perst_{assert/deassert}() to
maintain uniformity.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260115-pci-pwrctrl-rework-v5-15-9d26da3ce903@oss.qualcomm.com
For older targets like sc7280, we see reading DBI after sending PME turn off message is causing NOC error. To avoid unsafe DBI accesses, introduce qcom_pcie_get_ltssm(), which retrieves the LTSSM state from the PARF_LTSSM register instead. Link: https://lore.kernel.org/r/20260217-d3cold-v2-3-89b322864043@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
vbadigan
approved these changes
Feb 24, 2026
krishnachaitanya-linux
force-pushed
the
tech/bus/pci/all
branch
from
4e4ad7a to
ece9534
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For older targets like sc7280, we see reading DBI after sending PME turn off message is causing NOC error.
To avoid unsafe DBI accesses, introduce qcom_pcie_get_ltssm(), which retrieves the LTSSM state from the PARF_LTSSM register instead.
Link: https://lore.kernel.org/r/20260217-d3cold-v2-3-89b322864043@oss.qualcomm.com