summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-10platform/x86/amd: pmf: Use device managed allocationsMario Limonciello
If setting up smart PC fails for any reason then this can lead to a double free when unloading amd-pmf. This is because dev->buf was freed but never set to NULL and is again freed in amd_pmf_remove(). To avoid subtle allocation bugs in failures leading to a double free change all allocations into device managed allocations. Fixes: 5b1122fc4995f ("platform/x86/amd/pmf: fix cleanup in amd_pmf_init_smart_pc()") Link: https://lore.kernel.org/r/20250512211154.2510397-2-superm1@kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20250522003457.1516679-2-superm1@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-10ALSA: sb: Force to disable DMAs once when DMA mode is changedTakashi Iwai
When the DMA mode is changed on the (still real!) SB AWE32 after playing a stream and closing, the previous DMA setup was still silently kept, and it can confuse the hardware, resulting in the unexpected noises. As a workaround, enforce the disablement of DMA setups when the DMA setup is changed by the kcontrol. https://bugzilla.kernel.org/show_bug.cgi?id=218185 Link: https://patch.msgid.link/20250610064322.26787-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-06-10ALSA: sb: Don't allow changing the DMA mode during operationsTakashi Iwai
When a PCM stream is already running, one shouldn't change the DMA mode via kcontrol, which may screw up the hardware. Return -EBUSY instead. Link: https://bugzilla.kernel.org/show_bug.cgi?id=218185 Link: https://patch.msgid.link/20250610064322.26787-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-06-10ALSA: hda/realtek: Add quirk for Asus GU605CRichard Fitzgerald
The GU605C has similar audio hardware to the GU605M so apply the same quirk. Note that in the linked bugzilla there are two separate problems with the GU605C. This patch fixes one of the problems, so I haven't added a Closes: tag. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reported-by: Nick Karaolidis <nick@karaolidis.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=220152 Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20250609102125.63196-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-06-10ALSA: hda/realtek: Fix built-in mic on ASUS VivoBook X513EAChris Chiu
The built-in mic of ASUS VivoBook X513EA is broken recently by the fix of the pin sort. The fixup ALC256_FIXUP_ASUS_MIC_NO_PRESENCE is working for addressing the regression, too. Fixes: 3b4309546b48 ("ALSA: hda: Fix headset detection failure due to unstable sort") Signed-off-by: Chris Chiu <chris.chiu@canonical.com> Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20250610035607.690771-1-chris.chiu@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-06-09Merge tag 'powerpc-6.16-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Madhavan Srinivasan: - a couple of fixes for out of bounds issues in memtrace and vas Thanks to Ritesh Harjani (IBM), Haren Myneni, and Jonathan Greental * tag 'powerpc-6.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/vas: Return -EINVAL if the offset is non-zero in mmap() powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap
2025-06-10powerpc/vas: Return -EINVAL if the offset is non-zero in mmap()Haren Myneni
The user space calls mmap() to map VAS window paste address and the kernel returns the complete mapped page for each window. So return -EINVAL if non-zero is passed for offset parameter to mmap(). See Documentation/arch/powerpc/vas-api.rst for mmap() restrictions. Co-developed-by: Jonathan Greental <yonatan02greental@gmail.com> Signed-off-by: Jonathan Greental <yonatan02greental@gmail.com> Reported-by: Jonathan Greental <yonatan02greental@gmail.com> Fixes: dda44eb29c23 ("powerpc/vas: Add VAS user space API") Signed-off-by: Haren Myneni <haren@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250610021227.361980-2-maddy@linux.ibm.com
2025-06-10powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmapRitesh Harjani (IBM)
memtrace mmap issue has an out of bounds issue. This patch fixes the by checking that the requested mapping region size should stay within the allocated region size. Reported-by: Jonathan Greental <yonatan02greental@gmail.com> Fixes: 08a022ad3dfa ("powerpc/powernv/memtrace: Allow mmaping trace buffers") Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250610021227.361980-1-maddy@linux.ibm.com
2025-06-09scsi: error: alua: I/O errors for ALUA state transitionsRajashekhar M A
When a host is configured with a few LUNs and I/O is running, injecting FC faults repeatedly leads to path recovery problems. The LUNs have 4 paths each and 3 of them come back active after say an FC fault which makes 2 of the paths go down, instead of all 4. This happens after several iterations of continuous FC faults. Reason here is that we're returning an I/O error whenever we're encountering sense code 06/04/0a (LOGICAL UNIT NOT ACCESSIBLE, ASYMMETRIC ACCESS STATE TRANSITION) instead of retrying. Signed-off-by: Rajashekhar M A <rajs@netapp.com> Signed-off-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20250606135924.27397-1-hare@kernel.org Reviewed-by: Lee Duncan <lduncan@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-06-09scsi: storvsc: Increase the timeouts to storvsc_timeoutDexuan Cui
Currently storvsc_timeout is only used in storvsc_sdev_configure(), and 5s and 10s are used elsewhere. It turns out that rarely the 5s is not enough on Azure, so let's use storvsc_timeout everywhere. In case a timeout happens and storvsc_channel_init() returns an error, close the VMBus channel so that any host-to-guest messages in the channel's ringbuffer, which might come late, can be safely ignored. Add a "const" to storvsc_timeout. Cc: stable@kernel.org Signed-off-by: Dexuan Cui <decui@microsoft.com> Link: https://lore.kernel.org/r/1749243459-10419-1-git-send-email-decui@microsoft.com Reviewed-by: Long Li <longli@microsoft.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-06-09drm/msm/adreno: Check for recognized GPU before bindRob Clark
If we have a newer dtb than kernel, we could end up in a situation where the GPU device is present in the dtb, but not in the drivers device table. We don't want this to prevent the display from probing. So check that we recognize the GPU before adding the GPU component. v2: use %pOF Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/657701/
2025-06-09Merge tag 'for-net-2025-06-05' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - MGMT: Fix UAF on mgmt_remove_adv_monitor_complete - MGMT: Protect mgmt_pending list with its own lock - hci_core: fix list_for_each_entry_rcu usage - btintel_pcie: Increase the tx and rx descriptor count - btintel_pcie: Reduce driver buffer posting to prevent race condition - btintel_pcie: Fix driver not posting maximum rx buffers * tag 'for-net-2025-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: MGMT: Protect mgmt_pending list with its own lock Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete Bluetooth: btintel_pcie: Reduce driver buffer posting to prevent race condition Bluetooth: btintel_pcie: Increase the tx and rx descriptor count Bluetooth: btintel_pcie: Fix driver not posting maximum rx buffers Bluetooth: hci_core: fix list_for_each_entry_rcu usage ==================== Link: https://patch.msgid.link/20250605191136.904411-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-09net_sched: sch_sfq: fix a potential crash on gso_skb handlingEric Dumazet
SFQ has an assumption of always being able to queue at least one packet. However, after the blamed commit, sch->q.len can be inflated by packets in sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followed by an immediate drop. Fix sfq_drop() to properly clear q->tail in this situation. Tested: ip netns add lb ip link add dev to-lb type veth peer name in-lb netns lb ethtool -K to-lb tso off # force qdisc to requeue gso_skb ip netns exec lb ethtool -K in-lb gro on # enable NAPI ip link set dev to-lb up ip -netns lb link set dev in-lb up ip addr add dev to-lb 192.168.20.1/24 ip -netns lb addr add dev in-lb 192.168.20.2/24 tc qdisc replace dev to-lb root sfq limit 100 ip netns exec lb netserver netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & Fixes: a53851e2c321 ("net: sched: explicit locking in gso_cpu fallback") Reported-by: Marcus Wichelmann <marcus.wichelmann@hetzner-cloud.de> Closes: https://lore.kernel.org/netdev/9da42688-bfaa-4364-8797-e9271f3bdaef@hetzner-cloud.de/ Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Link: https://patch.msgid.link/20250606165127.3629486-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-09smb: client: disable path remapping with POSIX extensionsPhilipp Kerling
If SMB 3.1.1 POSIX Extensions are available and negotiated, the client should be able to use all characters and not remap anything. Currently, the user has to explicitly request this behavior by specifying the "nomapposix" mount option. Link: https://lore.kernel.org/4195bb677b33d680e77549890a4f4dd3b474ceaf.camel@rx2.rx-server.de Signed-off-by: Philipp Kerling <pkerling@casix.org> Reviewed-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-06-09drm/msm/adreno: Pass device_node to find_chipid()Rob Clark
We are going to want to re-use this before the component is bound, when we don't yet have the device pointer (but we do have the of node). v2: use %pOF Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/657705/
2025-06-09drm/msm: Rename add_components_mdp()Rob Clark
To better match add_gpu_components(). Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/657700/
2025-06-09drivers: gpu: drm: msm: registers: improve reproducibilityRyan Eatmon
The files generated by gen_header.py capture the source path to the input files and the date. While that can be informative, it varies based on where and when the kernel was built as the full path is captured. Since all of the files that this tool is run on is under the drivers directory, this modifies the application to strip all of the path before drivers. Additionally it prints <stripped> instead of the date. Signed-off-by: Ryan Eatmon <reatmon@ti.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/655599/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-06-09drm/msm/a7xx: Call CP_RESET_CONTEXT_STATEConnor Abbott
Calling this packet is necessary when we switch contexts because there are various pieces of state used by userspace to synchronize between BR and BV that are persistent across submits and we need to make sure that they are in a "safe" state when switching contexts. Otherwise a userspace submission in one context could cause another context to function incorrectly and hang, effectively a denial of service (although without leaking data). This was missed during initial a7xx bringup. Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support") Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/654924/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-06-09drm/msm: Fix CP_RESET_CONTEXT_STATE bitfield namesConnor Abbott
Based on kgsl. Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support") Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/654922/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-06-09Merge branch '6.16/scsi-queue' into 6.16/scsi-fixesMartin K. Petersen
Pull in remaining fixes from queue branch. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-06-09scsi: s390: zfcp: Ensure synchronous unit_addPeter Oberparleiter
Improve the usability of the unit_add sysfs attribute by ensuring that the associated FCP LUN scan processing is completed synchronously. This enables configuration tooling to consistently determine the end of the scan process to allow for serialization of follow-on actions. While the scan process associated with unit_add typically completes synchronously, it is deferred to an asynchronous background process if unit_add is used before initial remote port scanning has completed. This occurs when unit_add is used immediately after setting the associated FCP device online. To ensure synchronous unit_add processing, wait for remote port scanning to complete before initiating the FCP LUN scan. Cc: stable@vger.kernel.org Reviewed-by: M Nikhil <nikh1092@linux.ibm.com> Reviewed-by: Nihar Panda <niharp@linux.ibm.com> Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Nihar Panda <niharp@linux.ibm.com> Link: https://lore.kernel.org/r/20250603182252.2287285-2-niharp@linux.ibm.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-06-09scsi: iscsi: Fix incorrect error path labels for flashnode operationsAlok Tiwari
Correct the error handling goto labels used when host lookup fails in various flashnode-related event handlers: - iscsi_new_flashnode() - iscsi_del_flashnode() - iscsi_login_flashnode() - iscsi_logout_flashnode() - iscsi_logout_flashnode_sid() scsi_host_put() is not required when shost is NULL, so jumping to the correct label avoids unnecessary operations. These functions previously jumped to the wrong goto label (put_host), which did not match the intended cleanup logic. Use the correct exit labels (exit_new_fnode, exit_del_fnode, etc.) to ensure proper error handling. Also remove the unused put_host label under iscsi_new_flashnode() as it is no longer needed. No functional changes beyond accurate error path correction. Fixes: c6a4bb2ef596 ("[SCSI] scsi_transport_iscsi: Add flash node mgmt support") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Link: https://lore.kernel.org/r/20250530193012.3312911-1-alok.a.tiwari@oracle.com Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-06-09scsi: mvsas: Fix typos in per-phy comments and SAS cmd port registersAnkit Chauhan
Spelling fixes: Deocder --> Decoder Memroy --> Memory This is a non-functional change aimed at improving code clarity. Signed-off-by: Ankit Chauhan <ankitchauhan2065@gmail.com> Link: https://lore.kernel.org/r/20250528110604.59528-1-ankitchauhan2065@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-06-09drm/msm: Temporarily disable stall-on-fault after a page faultConnor Abbott
When things go wrong, the GPU is capable of quickly generating millions of faulting translation requests per second. When that happens, in the stall-on-fault model each access will stall until it wins the race to signal the fault and then the RESUME register is written. This slows processing page faults to a crawl as the GPU can generate faults much faster than the CPU can acknowledge them. It also means that all available resources in the SMMU are saturated waiting for the stalled transactions, so that other transactions such as transactions generated by the GMU, which shares translation resources with the GPU, cannot proceed. This causes a GMU watchdog timeout, which leads to a failed reset because GX cannot collapse when there is a transaction pending and a permanently hung GPU. On older platforms with qcom,smmu-v2, it seems that when one transaction is stalled subsequent faulting transactions are terminated, which avoids this problem, but the MMU-500 follows the spec here. To work around these problems, disable stall-on-fault as soon as we get a page fault until a cooldown period after pagefaults stop. This allows the GMU some guaranteed time to continue working. We only use stall-on-fault to halt the GPU while we collect a devcoredump and we always terminate the transaction afterward, so it's fine to miss some subsequent page faults. We also keep it disabled so long as the current devcoredump hasn't been deleted, because in that case we likely won't capture another one if there's a fault. After this commit HFI messages still occasionally time out, because the crashdump handler doesn't run fast enough to let the GMU resume, but the driver seems to recover from it. This will probably go away after the HFI timeout is increased. Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/654891/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-06-09drm/msm: Delete resume_translation()Connor Abbott
Unused since the previous commit. Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/654890/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-06-09drm/msm: Don't use a worker to capture fault devcoredumpConnor Abbott
Now that we use a threaded IRQ, it should be safe to do this in the fault handler. We can also remove fault_info from struct msm_gpu and just pass it directly. Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/654889/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-06-09drm/msm: Fix another leak in the submit error pathRob Clark
put_unused_fd() doesn't free the installed file, if we've already done fd_install(). So we need to also free the sync_file. Signed-off-by: Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/653583/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-06-09drm/msm: Fix a fence leak in submit error pathRob Clark
In error paths, we could unref the submit without calling drm_sched_entity_push_job(), so msm_job_free() will never get called. Since drm_sched_job_cleanup() will NULL out the s_fence, we can use that to detect this case. Signed-off-by: Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/653584/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-06-09SPI: omap2-mcspi: Fix SPI CS behaviour aroundMark Brown
Merge series from Félix Piédallu <felix.piedallu@non.se.com>: These patches fix the behaviour of the SPI Chip Select of the OMAP2 MCSPI driver used on TI SoCs. The omap2-mcspi driver supports the use of multi mode (multichannel in TI documentation). In this mode, the CS is asserted and deasserted by the hardware. The multi mode is disabled for messages when cs_change=0 for all transfers (e.g when CS is kept asserted between transfers of a same message). The multi mode also needs to be disabled for messages when cs_change=1 on the last transfer (e.g when CS is kept asserted after the WHOLE message), and the message right after. Currently, that is not the case and it CS is deasserted by hardware when it shouldn't. This breaks peripheral drivers that send multiple messages with the CS asserted in between. Patch 1 ensures that multi mode is disabled when cs_change=1 on the last transfer of the message. Patch 2 ensures that multi mode is disable on a message following one with cs_change=1 on the last transfer. This is the case for the TPM TIS SPI driver that uses this logic for flow control purposes. Tested on an AM6442 platform with a TPM ST33HTPH2X32AHE4.
2025-06-09ARM: dts: bcm958625-meraki-mx6x: Use #pwm-cells = <3>Uwe Kleine-König
bcm-nsp.dtsi has #pwm-cells = <3> as is specified in the binding. So to also use that correct value for bcm958625-meraki-mx6x the property overriding that value just has to be dropped. This fixes a few warnings like: arch/arm/boot/dts/broadcom/bcm958625-meraki-mx65.dtb: pwm@31000: #pwm-cells: 3 was expected from schema $id: http://devicetree.org/schemas/pwm/brcm,iproc-pwm.yaml# Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250527181320.373572-2-u.kleine-koenig@baylibre.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM: dts: bcm63178: Add BCMBCA peripheralsLinus Walleij
All the BCMBCA SoCs share a set of peripherals at 0xff800000, albeit at slightly varying memory locations on the bus and with varying IRQ assignments. Add the watchdog, GPIO, RNG, LED and DMA blocks for the BCM63178 based on the vendor files 63178_map_part.h and 63178_intr.h from the "bcmopen-consumer" code drop. This SoC has up to 256 possible GPIOs due to having 8 registers with 32 GPIOs in each available. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-8-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM: dts: bcm63148: Add BCMBCA peripheralsLinus Walleij
All the BCMBCA SoCs share a set of peripherals at 0xff800000, albeit at slightly varying memory locations on the bus and with varying IRQ assignments. Add the GPIO, RNG and LED and DMA blocks for the BCM63148 based on the vendor files 63148_map_part.h and 63148_intr.h from the "bcmopen-consumer" code drop. This SoC has up to 160 possible GPIOs due to having 5 registers with 32 GPIOs in each available. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-7-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM: dts: bcm63138: Add BCMBCA peripheralsLinus Walleij
All the BCMBCA SoCs share a set of peripherals at 0xff800000, albeit at slightly varying memory locations on the bus and with varying IRQ assignments. Extend the peripheral interrupt window to 0x10000 as it need to fit the DMA block. Add the GPIO, RNG and LED and DMA blocks for the BCM63138 based on the vendor files 63138_map_part.h and 63138_intr.h from the "bcmopen-consumer" code drop. This SoC has up to 160 possible GPIOs due to having 5 registers with 32 GPIOs in each available. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-6-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM: dts: bcm6878: Add BCMBCA peripheralsLinus Walleij
All the BCMBCA SoCs share a set of peripherals at 0xff800000, albeit at slightly varying memory locations on the bus and with varying IRQ assignments. Add the first and second watchdog, GPIO, RNG, LED and DMA blocks for the BCM6878 based on the vendor files 6878_map_part.h and 6878_intr.h from the "bcmopen-consumer" code drop. This SoC has up to 256 possible GPIOs due to having 8 registers with 32 GPIOs in each available. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-5-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM: dts: bcm6855: Add BCMBCA peripheralsLinus Walleij
All the BCMBCA SoCs share a set of peripherals at 0xff800000, albeit at slightly varying memory locations on the bus and with varying IRQ assignments. Add the first and second watchdog, GPIO, RNG, LED, DMA and second PL011 UART blocks for the BCM6855 based on the vendor files 6855_map_part.h and 6855_intr.h from the "bcmopen-consumer" code drop. This SoC has up to 256 possible GPIOs due to having 8 registers with 32 GPIOs in each available. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-4-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM: dts: bcm6846: Add interrupt to RNGLinus Walleij
The r200 RNG has an interrupt so let's add it. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-3-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09dt-bindings: rng: r200: Add interrupt propertyLinus Walleij
This IP block has an interrupt. Add it and add it to the example as well. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-2-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM: dts: bcm6878: Correct UART0 IRQ numberLinus Walleij
According to the vendor file 6878_intr.h the UART0 has IRQ 92, not 32. Assuming this is a copy-and-paste error. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-1-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09arm64: dts: broadcom: Add overlay for RP1 deviceAndrea della Porta
Define the RP1 node in an overlay. The inclusion tree is as follow (the arrow points to the includer): rp1.dtso ^ | rp1-common.dtsi ----> rp1-nexus.dtsi Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20250529135052.28398-10-andrea.porta@suse.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09arm64: dts: broadcom: Add board DTS for Rpi5 which includes RP1 nodeAndrea della Porta
Add the fully populated DTS for RaspberryPi 5 which includes the RP1 node definition. The inclusion tree is as follow (the arrow points to the includer): rp1-common.dtsi ----> rp1-nexus.dtsi ----> bcm2712-rpi-5-b.dts ^ | bcm2712-rpi-5-b-ovl-rp1.dts This is designed to maximize the compatibility with downstream DT while ensuring that a fully defined DT (one which includes the RP1 node as opposed to load it from overlay at runtime) is present since early boot stage. Since the preferred board DT is the fully populated one, name it bcm2712-rpi-5-b.dts and move the previous one into bcm2712-rpi-5-b-ovl-rp1.dts. Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Link: https://lore.kernel.org/r/20250529135052.28398-9-andrea.porta@suse.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09arm64: dts: bcm2712: Add external clock for RP1 chipset on Rpi5Andrea della Porta
The RP1 found on Raspberry Pi 5 board needs an external crystal at 50MHz. Add clk_rp1_xosc node to provide that. Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20250529135052.28398-8-andrea.porta@suse.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09arm64: dts: rp1: Add support for RaspberryPi's RP1 deviceAndrea della Porta
RaspberryPi RP1 is a multi function PCI endpoint device that exposes several subperipherals via PCI BAR. Add a dtb overlay that will be compiled into a binary blob and linked in the RP1 driver. This overlay offers just minimal support to represent the RP1 device itself, the sub-peripherals will be added by future patches. Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20250529135052.28398-6-andrea.porta@suse.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09dt-bindings: misc: Add device specific bindings for RaspberryPi RP1Andrea della Porta
The RP1 is a MFD that exposes its peripherals through PCI BARs. This schema is intended as minimal support for the clock generator and gpio controller peripherals which are accessible through BAR1. Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20250529135052.28398-3-andrea.porta@suse.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09dt-bindings: pinctrl: Add RaspberryPi RP1 gpio/pinctrl/pinmux bindingsAndrea della Porta
Add device tree bindings for the gpio/pin/mux controller that is part of the RP1 multi function device, and relative entries in MAINTAINERS file. Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20250529135052.28398-2-andrea.porta@suse.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09dt-bindings: clock: Add RaspberryPi RP1 clock bindingsAndrea della Porta
Add device tree bindings for the clock generator found in RP1 multi function device, and relative entries in MAINTAINERS file. Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20250529135052.28398-1-andrea.porta@suse.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM64: dts: bcm63158: Add BCMBCA peripheralsLinus Walleij
All the BCMBCA SoCs share a set of peripherals at 0xff800000, albeit at slightly varying memory locations on the bus and with varying IRQ assignments. Add the watchdog, GPIO blocks, RNG, LED, second UART and DMA blocks for the BCM63158 based on the vendor files 63158_map_part.h and 63158_intr.h from the "bcmopen-consumer" code drop. The DTSI file has clearly been authored for the B0 revision of the SoC: there is an earlier A0 version, but this has the UARTs in the legacy PERF memory space, while the B0 has opened a new peripheral window at 0xff812000 for the three UARTs. It also has a designated AHB peripheral area at 0xff810000 where the DMA resides, the peripheral range window fits these two peripheral groups. This SoC has up to 256 possible GPIOs due to having 8 registers with 32 GPIOs in each available. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-12-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM64: dts: bcm6858: Add BCMBCA peripheralsLinus Walleij
All the BCMBCA SoCs share a set of peripherals at 0xff800000, albeit at slightly varying memory locations on the bus and with varying IRQ assignments. ARM64 SoCs have additional peripherals at 0xff858000. Extend the peripheral window range to 0x400000 and add the DMA controller at offset 0x59000. Add the watchdog, GPIO blocks, RNG, LED, second UART and DMA blocks for the BCM6858 based on the vendor files 6858_map_part.h and 6858_intr.h from the "bcmopen-consumer" code drop. This SoC has up to 256 possible GPIOs due to having 8 registers with 32 GPIOs in each available. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-11-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM64: dts: bcm6856: Add BCMBCA peripheralsLinus Walleij
All the BCMBCA SoCs share a set of peripherals at 0xff800000, albeit at slightly varying memory locations on the bus and with varying IRQ assignments. ARM64 SoCs have additional peripherals at 0xff858000. Extend the BCM6856 the PERF window to 0x400000 and add the DMA block at offset 0x59000. Add the watchdog, GPIO blocks, RNG, LED, second UART and DMA blocks for the BCM6856 based on the vendor files 6856_map_part.h and 6856_intr.h from the "bcmopen-consumer" code drop. This SoC has up to 256 possible GPIOs due to having 8 registers with 32 GPIOs in each available. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-10-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM64: dts: bcm4908: Add BCMBCA peripheralsLinus Walleij
All the BCMBCA SoCs share a set of peripherals at 0xff800000, albeit at slightly varying memory locations on the bus and with varying IRQ assignments. ARM64 SoCs have additional peripherals at 0xff858000, we extend the peripheral bus range to 0x400000 to cover this area. Add the watchdog, remaining GPIO blocks, RNG, and DMA blocks for the BCM4908 based on the vendor files 4908_map_part.h and 4908_intr.h from the "bcmopen-consumer" code drop. This SoC has up to 320 possible GPIOs due to having 10 registers with 32 GPIOs in each available. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-9-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARC: Replace __ASSEMBLY__ with __ASSEMBLER__ in the non-uapi headersThomas Huth
While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembly code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This can be very confusing when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. So let's standardize on the __ASSEMBLER__ macro that is provided by the compilers now. This is a completely mechanical patch (done with a simple "sed -i" statement). Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Vineet Gupta <vgupta@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-21 04:53:19 +0000