summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-04-25x86/sev: Make the VMPL0 checking more straight forwardTom Lendacky
Currently, the enforce_vmpl0() function uses a set argument when modifying the VMPL1 permissions used to test for VMPL0. If the guest is not running at VMPL0, the guest self-terminates. The function is just a wrapper for a fixed RMPADJUST function. Eliminate the function and perform the RMPADJUST directly. No functional change. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/ed01ddf04bfb475596b24b634fd26cffaa85173a.1713974291.git.thomas.lendacky@amd.com
2024-04-25x86/sev: Rename snp_init() in boot/compressed/sev.cTom Lendacky
The snp_init() function in boot/compressed/sev.c is local to that file, is not called from outside of the file and is independent of the snp_init() function in kernel/sev.c. Change the name to better differentiate when each function is used. Move the renamed snp_init() and related functions up in the file to avoid having to add a forward declaration and make the function static. No functional change. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/afda29585c2724b9698003f24cefa77eb35f4ffb.1713974291.git.thomas.lendacky@amd.com
2024-04-25x86/sev: Shorten struct name snp_secrets_page_layout to snp_secrets_pageTom Lendacky
Ending a struct name with "layout" is a little redundant, so shorten the snp_secrets_page_layout name to just snp_secrets_page. No functional change. [ bp: Rename the local pointer to "secrets" too for more clarity. ] Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/bc8d58302c6ab66c3beeab50cce3ec2c6bd72d6c.1713974291.git.thomas.lendacky@amd.com
2024-04-25block: check if zone_wplugs_hash exists in queue_zone_wplugs_showJohannes Thumshirn
Changhui reported a kernel crash when running this simple shell reproducer: # cd /sys/kernel/debug/block && find . -type f -exec grep -aH . {} \; The above results in a NULL pointer dereference if a device does not have a zone_wplugs_hash allocated. To fix this, return early if we don't have a zone_wplugs_hash. Reported-by: Changhui Zhong <czhong@redhat.com> Fixes: a98b05b02f0f ("block: Replace zone_wlock debugfs entry with zone_wplugs entry") Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Link: https://lore.kernel.org/r/e5fec079dfca448cc21c425cfa5d7b291f5faa67.1714046443.git.johannes.thumshirn@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-04-25cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=nSean Christopherson
Explicitly disallow enabling mitigations at runtime for kernels that were built with CONFIG_CPU_MITIGATIONS=n, as some architectures may omit code entirely if mitigations are disabled at compile time. E.g. on x86, a large pile of Kconfigs are buried behind CPU_MITIGATIONS, and trying to provide sane behavior for retroactively enabling mitigations is extremely difficult, bordering on impossible. E.g. page table isolation and call depth tracking require build-time support, BHI mitigations will still be off without additional kernel parameters, etc. [ bp: Touchups. ] Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20240420000556.2645001-3-seanjc@google.com
2024-04-25cpu: Re-enable CPU mitigations by default for !X86 architecturesSean Christopherson
Rename x86's to CPU_MITIGATIONS, define it in generic code, and force it on for all architectures exception x86. A recent commit to turn mitigations off by default if SPECULATION_MITIGATIONS=n kinda sorta missed that "cpu_mitigations" is completely generic, whereas SPECULATION_MITIGATIONS is x86-specific. Rename x86's SPECULATIVE_MITIGATIONS instead of keeping both and have it select CPU_MITIGATIONS, as having two configs for the same thing is unnecessary and confusing. This will also allow x86 to use the knob to manage mitigations that aren't strictly related to speculative execution. Use another Kconfig to communicate to common code that CPU_MITIGATIONS is already defined instead of having x86's menu depend on the common CPU_MITIGATIONS. This allows keeping a single point of contact for all of x86's mitigations, and it's not clear that other architectures *want* to allow disabling mitigations at compile-time. Fixes: f337a6a21e2f ("x86/cpu: Actually turn off mitigations by default for SPECULATION_MITIGATIONS=n") Closes: https://lkml.kernel.org/r/20240413115324.53303a68%40canb.auug.org.au Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: Michael Ellerman <mpe@ellerman.id.au> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240420000556.2645001-2-seanjc@google.com
2024-04-25arm64: dts: st: correct masks for GIC PPI interrupts on stm32mp25Patrick Delaunay
Using GIC_CPU_MASK_SIMPLE(x), x should reflect the number of CPUs. STM32MP251 is a single core Cortex A35, STM32MP253 is a dual core CA35. Fixes: 5d30d03aaf78 ("arm64: dts: st: introduce stm32mp25 SoCs family") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25arm64: dts: st: add spi3 / spi8 properties on stm32mp257f-ev1Alain Volmat
Add properties for spi3 and spi8 available on the stm32mp257f-ev1. Both are kept disabled since only used via the gpio expansion connector. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25arm64: dts: st: add spi3/spi8 pins for stm32mp25Alain Volmat
Add the spi3 and spi8 pins used on STM32MP257F-EV1 board. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25arm64: dts: st: add all 8 spi nodes on stm32mp251Alain Volmat
Add the 8 nodes for all spi instances available on the stm32mp251. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25arm64: dts: st: add i2c2 / i2c8 properties on stm32mp257f-ev1Alain Volmat
Add properties for i2c2 and i2c8 available on the stm32mp257f-ev1. i2c2 is enabled since several devices are attached to it while i2c8 is kept disabled since only used via the gpio expansion connector. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25arm64: dts: st: add i2c2/i2c8 pins for stm32mp25Alain Volmat
Add the i2c2 and i2c8 pins used on STM32MP257F-EV1 board. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25arm64: dts: st: add all 8 i2c nodes on stm32mp251Alain Volmat
Add the 8 nodes for all i2c instances available on the stm32mp251. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25arm64: dts: st: add rcc support for STM32MP25Gabriel Fernandez
Add RCC support to manage clocks and resets on the STM32MP25. Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25ARM: dts: stm32: enable display support on stm32mp135f-dk boardRaphael Gallais-Pou
Link panel and display controller. Enable panel, backlight and display controller. Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25ARM: dts: stm32: add LTDC pinctrl on STM32MP13x SoC familyRaphael Gallais-Pou
Adds LTDC pinctrl support and assigns dedicated GPIO pins. Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25ARM: dts: stm32: add LTDC support for STM32MP13x SoC familyRaphael Gallais-Pou
STM32MP13x SoC family embeds a new version of LTDC (Liquid crystal display - Thin film transistor) Display Controller. It provides a parallel digital RGB (red, green, blue) and signals for horizontal, vertical synchronization, pixel clock and data enable as output to interface directly to a variety of LCD-TFT panels. Main features * 2 input layers blended together to compose the display * Cropping of layers from any input size and location * Multiple input pixel formats: – Predefined ARGB, with 7 formats: ARGB8888, ABGR8888, RGBA8888, BGRA8888, RGB565, BGR565, RGB888packed. – Flexible ARGB, allowing any width and location for A,R,G,B components. – Predefined YUV, with 3 formats: YUV422-1L (FourCC: YUYV, Interleaved), YUV420-2L (FourCC: NV12, semi planar), YUV420-3L (FourCC: Yxx, full planar) with some flexibility on the sequence of the component. * Color look-up table (CLUT) up to 256 colors (256x24 bits) per layer * Color transparency keying * Composition with flexible window position and size versus output display * Blending with flexible layer order and alpha value (per pixel or constant) * Background underlying color * Gamma with non-linear configurable table * Dithering for output with less bits per component (pseudo-random on 2 bits) * Polarity inversion for HSync, VSync, and DataEnable outputs * Output as RGB888 24 bpp or YUV422 16 bpp * Secure layer (using Layer2) capability, with grouped regs and additional interrupt set * Interrupts based on 7 different events * AXI master interface with long efficient bursts (64 or 128 bytes) Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25dt-bindings: display: simple: allow panel-common propertiesRaphael Gallais-Pou
This device inherits properties from panel-common. Those should be allowed to use, instead of specifying properties to true for each specific use. Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25ARM: dts: stm32: add PWR regulators support on stm32mp131Marek Vasut
This patch adds STM32 PWR regulators DT support on stm32mp131. This requires TFA to clear RCC_SECCFGR, is disabled by default and can only be enabled on board DT level. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25media: dt-bindings: add access-controllers to STM32MP25 video codecsHugues Fruchet
access-controllers is an optional property that allows a peripheral to refer to one or more domain access controller(s). Signed-off-by: Hugues Fruchet <hugues.fruchet@foss.st.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25ARM: dts: stm32: add heartbeat led for stm32mp157c-ed1Patrice Chotard
Add heartbeat led for stm32mp157c-ed1. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25ARM: dts: stm32: move can3 node from stm32f746 to stm32f769Dario Binacchi
According to documents [1], [2] and [3], we have 2 CAN devices on the stm32f746 platform and 3 on the stm32f769 platform. So let's move the can3 node from stm32f746.dtsi to stm32f769.dtsi. [1] https://www.st.com/en/microcontrollers-microprocessors/stm32f7-series.html [2] RM0385: STM32F75xxx and STM32F74xxx advanced Arm®-based 32-bit MCUs [3] RM0410: STM32F76xxx and STM32F77xxx advanced Arm®-based 32-bit MCUs Fixes: df362914eead ("ARM: dts: stm32: re-add CAN support on stm32f746") Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25ARM: dts: stm32: put ETZPC as an access controller for STM32MP13x boardsAlexandre Torgue
Reference ETZPC as an access-control-provider. For more information on which peripheral is securable or supports MCU isolation, please read the STM32MP13 reference manual Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boardsGatien Chevallier
ETZPC is a firewall controller. Put all peripherals filtered by the ETZPC as ETZPC subnodes and keep the "simple-bus" compatible for backward compatibility. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25ARM: dts: stm32: put ETZPC as an access controller for STM32MP15x boardsGatien Chevallier
Reference ETZPC as an access-control-provider. For more information on which peripheral is securable or supports MCU isolation, please read the STM32MP15 reference manual Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boardsGatien Chevallier
ETZPC is a firewall controller. Put all peripherals filtered by the ETZPC as ETZPC subnodes and keep the "simple-bus" compatible for backward compatibility. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25arm64: dts: st: add RIFSC as an access controller for STM32MP25x boardsGatien Chevallier
RIFSC is a firewall controller. Add "st,stm32mp25-rifsc" compatible and reference RIFSC as an access-control-provider. Keep "simple-bus" compatible backward compatibility. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25exfat: zero the reserved fields of file and stream extension dentriesYuezhang Mo
From exFAT specification, the reserved fields should initialize to zero and should not use for any purpose. If create a new dentry set in the UNUSED dentries, all fields had been zeroed when allocating cluster to parent directory. But if create a new dentry set in the DELETED dentries, the reserved fields in file and stream extension dentries may be non-zero. Because only the valid bit of the type field of the dentry is cleared in exfat_remove_entries(), if the type of dentry is different from the original(For example, a dentry that was originally a file name dentry, then set to deleted dentry, and then set as a file dentry), the reserved fields is non-zero. So this commit initializes the dentry to 0 before createing file dentry and stream extension dentry. Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Reviewed-by: Andy Wu <Andy.Wu@sony.com> Reviewed-by: Aoyama Wataru <wataru.aoyama@sony.com> Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
2024-04-25bus: stm32_firewall: fix off by one in stm32_firewall_get_firewall()Dan Carpenter
The "nb_firewall" variable is the number of elements in the firewall[] array, which is allocated in stm32_firewall_populate_bus(). So change this > comparison to >= to prevent an out of bound access. Fixes: 5c9668cfc6d7 ("firewall: introduce stm32_firewall framework") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25bus: etzpc: introduce ETZPC firewall controller driverGatien Chevallier
ETZPC is a peripheral and memory firewall controller that filter accesses based on Arm TrustZone secure state and Arm CPU privilege execution level. It handles MCU isolation as well. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-04-25Merge tag 'intel-gpio-v6.9-2' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel into gpio/for-current intel-gpio for v6.9-2 * Make data pointer dereference robust in Intel Tangier driver The following is an automated git shortlog grouped by driver: tangier: - Use correct type for the IRQ chip data
2024-04-25Merge tag 'intel-pinctrl-v6.9-1' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into fixes intel-pinctrl for v6.9-1 * Correct GPIO selection and add UART3 pins for Intel Bay Trail The following is an automated git shortlog grouped by driver: baytrail: - Add pinconf group for uart3 - Fix selecting gpio pinctrl state Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2024-04-25irqchip/gic-v3-its: Prevent double free on errorGuanrui Huang
The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ] Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Guanrui Huang <guanrui.huang@linux.alibaba.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240418061053.96803-2-guanrui.huang@linux.alibaba.com
2024-04-25Merge tag 'renesas-pinctrl-fixes-for-v6.9-tag2' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into fixes pinctrl: renesas: Fixes for v6.9 (take two) - Fix interrupt configuration on RZ/G2L after s2ram. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2024-04-25iomap: do some small logical cleanup in buffered writeZhang Yi
Since iomap_write_end() can never return a partial write length, the comparison between written, copied and bytes becomes useless, just merge them with the unwritten branch. Signed-off-by: Zhang Yi <yi.zhang@huawei.com> Link: https://lore.kernel.org/r/20240320110548.2200662-10-yi.zhang@huaweicloud.com Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-04-25iomap: make iomap_write_end() return a booleanZhang Yi
For now, we can make sure iomap_write_end() always return 0 or copied bytes, so instead of return written bytes, convert to return a boolean to indicate the copied bytes have been written to the pagecache. Signed-off-by: Zhang Yi <yi.zhang@huawei.com> Link: https://lore.kernel.org/r/20240320110548.2200662-9-yi.zhang@huaweicloud.com Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-04-25iomap: use a new variable to handle the written bytes in iomap_write_iter()Zhang Yi
In iomap_write_iter(), the status variable used to receive the return value from iomap_write_end() is confusing, replace it with a new written variable to represent the written bytes in each cycle, no logic changes. Signed-off-by: Zhang Yi <yi.zhang@huawei.com> Link: https://lore.kernel.org/r/20240320110548.2200662-8-yi.zhang@huaweicloud.com Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-04-25iomap: don't increase i_size if it's not a write operationZhang Yi
Increase i_size in iomap_zero_range() and iomap_unshare_iter() is not needed, the caller should handle it. Especially, when truncate partial block, we should not increase i_size beyond the new EOF here. It doesn't affect xfs and gfs2 now because they set the new file size after zero out, it doesn't matter that a transient increase in i_size, but it will affect ext4 because it set file size before truncate. So move the i_size updating logic to iomap_write_iter(). Signed-off-by: Zhang Yi <yi.zhang@huawei.com> Link: https://lore.kernel.org/r/20240320110548.2200662-7-yi.zhang@huaweicloud.com Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-04-25iomap: drop the write failure handles when unsharing and zeroingZhang Yi
Unsharing and zeroing can only happen within EOF, so there is never a need to perform posteof pagecache truncation if write begin fails, also partial write could never theoretically happened from iomap_write_end(), so remove both of them. Signed-off-by: Zhang Yi <yi.zhang@huawei.com> Link: https://lore.kernel.org/r/20240320110548.2200662-6-yi.zhang@huaweicloud.com Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-04-25arm64: dts: ti: k3-j784s4: Use exact ranges for FSS nodeAndrew Davis
The FSS bus contains several register ranges. Using an empty ranges property works but causes a DT warning when we give this node an address. Fix this by explicitly defining the memory ranges in use. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240326205920.40147-4-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-04-25arm64: dts: ti: k3-j721e: Use exact ranges for FSS nodeAndrew Davis
The FSS bus contains several register ranges. Using an empty ranges property works but causes a DT warning when we give this node an address. Fix this by explicitly defining the memory ranges in use. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240326205920.40147-3-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-04-25arm64: dts: ti: k3-j7200: Use exact ranges for FSS nodeAndrew Davis
The FSS bus contains several register ranges. Using an empty ranges property works but causes a DT warning when we give this node an address. Fix this by explicitly defining the memory ranges in use. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240326205920.40147-2-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-04-25arm64: dts: ti: k3-am65: Use exact ranges for FSS nodeAndrew Davis
The FSS bus contains several register ranges. Using an empty ranges property works but causes a DT warning when we give this node an address. Fix this by explicitly defining the memory ranges in use. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240326205920.40147-1-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-04-25arm64: dts: ti: k3-am65: Move SerDes mux nodes under the control nodeAndrew Davis
These SerDes lane select muxes use bits from the same register as the SerDes clock select mux. Make the lane select mux a child of the SerDes control node. This removes one more requirement on scm-conf being a syscon node which will later be converted to fix a couple DTS check warnings. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240326185627.29852-2-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-04-25arm64: dts: ti: k3-am65: Add full compatible to SerDes control nodesAndrew Davis
This matches the binding for this register region which fixes a couple DTS check warnings. While here trim the leading 0s from the "reg" definition. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240326185627.29852-1-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-04-25firmware: arm_ffa: Avoid queuing work when running on the worker queueSudeep Holla
Currently notif_pcpu_irq_work_fn() may get queued from the work that is already running on the 'notif_pcpu_wq' workqueue. This may add unnecessary delays and could be avoided if the work is called directly instead. This change removes queuing of the work when already running on the 'notif_pcpu_wq' workqueue thereby removing any possible delays in that path. Link: https://lore.kernel.org/r/20240424131640.706870-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-04-25Merge tag 'wireless-2024-04-23' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes berg says: ==================== Fixes for the current cycle: * ath11k: convert to correct RCU iteration of IPv6 addresses * iwlwifi: link ID, FW API version, scanning and PASN fixes * cfg80211: NULL-deref and tracing fixes * mac80211: connection mode, mesh fast-TX, multi-link and various other small fixes ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2024-04-25x86/bugs: Switch to new Intel CPU model definesTony Luck
New CPU #defines encode vendor and family as well as model. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://lore.kernel.org/r/20240424181507.41693-1-tony.luck@intel.com
2024-04-25x86/bugs: Switch to new Intel CPU model definesTony Luck
New CPU #defines encode vendor and family as well as model. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://lore.kernel.org/r/20240424181506.41673-1-tony.luck@intel.com
2024-04-25net: phy: dp83869: Fix MII mode failureMD Danish Anwar
The DP83869 driver sets the MII bit (needed for PHY to work in MII mode) only if the op-mode is either DP83869_100M_MEDIA_CONVERT or DP83869_RGMII_100_BASE. Some drivers i.e. ICSSG support MII mode with op-mode as DP83869_RGMII_COPPER_ETHERNET for which the MII bit is not set in dp83869 driver. As a result MII mode on ICSSG doesn't work and below log is seen. TI DP83869 300b2400.mdio:0f: selected op-mode is not valid with MII mode icssg-prueth icssg1-eth: couldn't connect to phy ethernet-phy@0 icssg-prueth icssg1-eth: can't phy connect port MII0 Fix this by setting MII bit for DP83869_RGMII_COPPER_ETHERNET op-mode as well. Fixes: 94e86ef1b801 ("net: phy: dp83869: support mii mode when rgmii strap cfg is used") Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Reviewed-by: Ravi Gunasekaran <r-gunasekaran@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>