summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-11net: txgbe: distinguish module types by checking identifierJiawen Wu
Rework txgbe_identify_module() to validate module identifiers through explicit type checks instead of relying on transceiver_type heuristics. When using the SFP module, transceiver_type could be a random value, because it was read from an invalid register. Fixes: 57d39faed4c9 ("net: txgbe: improve functions of AML 40G devices") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Link: https://patch.msgid.link/20260608070842.36504-3-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-11net: txgbe: initialize module info bufferJiawen Wu
The module info buffer should be initialized to 0 before the firmware returns information. Otherwise, there is a risk that the buffer field not filled by the firmware is random value. Fixes: 343929799ace ("net: txgbe: Support to handle GPIO IRQs for AML devices") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Link: https://patch.msgid.link/20260608070842.36504-2-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-11gpio: nomadik: remove dead DB8540 code from <gpio/gpio-nomadik.h>Ethan Nelson-Moore
DB8540 support was removed in commit b6d09f780761 ("pinctrl: nomadik: Drop U8540/9540 support"), but a couple small pieces of related code remained in <gpio/gpio-nomadik.h>. Remove them. Discovered while searching for CONFIG_* symbols referenced in code but not defined in any Kconfig file. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260610205007.44881-1-enelsonmoore@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-11x86/cpu: Make CONFIG_X86_CX8 unconditionalIngo Molnar
I.e. from now on it's a boot time requirement for the CPU to support it. ( This was preceded by the removal of all non-CX8 platform build options, so it should have no functional effects in theory. ) Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ahmed S . Darwish <darwi@linutronix.de> Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: H . Peter Anvin <hpa@zytor.com> Cc: John Ogness <john.ogness@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20250425084216.3913608-14-mingo@kernel.org
2026-06-11x86/cpu: Remove unused !CONFIG_X86_TSC codeIngo Molnar
Now that the Kconfig space always enables CONFIG_X86_TSC (on x86), remove !CONFIG_X86_TSC code from the x86 arch code. We still keep the Kconfig option to catch any eventual code still pending in maintainer or non-mainline trees, plus some drivers have raw TSC timestamping hacks that use CONFIG_X86_TSC. It's also still possible to disable TSC support runtime. Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ahmed S . Darwish <darwi@linutronix.de> Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: H . Peter Anvin <hpa@zytor.com> Cc: John Ogness <john.ogness@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20250425084216.3913608-13-mingo@kernel.org
2026-06-11m68k: stmark2: enable DACs outputsAngelo Dureghello
Enabled DAC0 and DAC1 outpus disabling shared ADC inputs on ADC3 and ADC7. Reviewed-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: stmark2: add mcf5441x DAC platform devicesAngelo Dureghello
Add mcf5441x DAC platform devices. Reviewed-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: stmark2: use ioport.h macros for resourcesAngelo Dureghello
Change resource declaration using DEFINE_RES_*() macros. DEFINE_DMA_RES() is for a single dma channel, not a range, so used twice. Also, some drivers assume IRQ resources are from index 1, so just to stay uniform, moved IRQ resource at index 1. Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: mcf5441x: add CCR MISCCR2 bitfieldsAngelo Dureghello
Add CCR MISCCR2 register bitfields. Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: mcf5441x: add CCM registersAngelo Dureghello
Add CCM module register offsets. Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: add DAC modules base addressesAngelo Dureghello
Add DAC controller 0 and 1 base addresses. Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: mcf5441x: add clock for DAC channel 1Angelo Dureghello
Add missing clock for mcf5441x DAC channel 1. Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: mcf5441x: fix clocks numberingAngelo Dureghello
Fix clocks numbering, set correct values for eport and DAC, as per RM Rev 5, 05/2018, table 9.5. Fixes: bea8bcb12da09 ("m68knommu: Add support for the Coldfire m5441x.") Fixes: 007f84ede6e3e ("m68k: coldfire: remove private clk_get/clk_put") Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11Merge branch 'net-mvpp2-fix-xdp-rx-buffer-handling'Paolo Abeni
Til Kaiser says: ==================== net: mvpp2: fix XDP RX buffer handling This is v5 of the earlier XDP_PASS fix. The XDP_PASS change is retained, and the series also fixes related RX/XDP buffer handling issues found during review. Tested with tools/testing/selftests/drivers/net/xdp.py on mvpp2 hardware. ==================== Link: https://patch.msgid.link/20260607134943.21996-1-mail@tk154.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-11net: mvpp2: build skb from XDP-adjusted data on XDP_PASSTil Kaiser
When an XDP program uses bpf_xdp_adjust_head() or bpf_xdp_adjust_tail() and then returns XDP_PASS, mvpp2 still builds the skb from fixed offsets derived from the original RX descriptor. Packet geometry changes made by the XDP program are therefore discarded before the skb reaches the stack. Update rx_offset and rx_bytes from xdp.data and xdp.data_end for XDP_PASS. This makes skb_reserve() and skb_put() reflect the packet seen by XDP, and makes RX byte accounting for XDP_PASS follow the length of the skb passed to the network stack. Keep a separate rx_sync_size for page-pool recycling on skb allocation failure, which must stay tied to the received buffer range. Non-PASS verdicts continue to account the descriptor length because no skb is passed up in those cases. Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support") Signed-off-by: Til Kaiser <mail@tk154.de> Link: https://patch.msgid.link/20260607134943.21996-5-mail@tk154.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-11net: mvpp2: refill RX buffers before XDP or skb useTil Kaiser
The RX error path returns the current descriptor buffer to the hardware BM pool. That is only valid while the driver still owns the buffer. mvpp2_rx_refill() can fail after the current buffer has been handed to XDP or attached to an skb. In those cases mvpp2_run_xdp() may have recycled, redirected, or queued the page for XDP_TX, and an skb free also retires the data buffer. Returning such a buffer to BM lets hardware DMA into memory that is no longer owned by the RX ring. Refill the BM pool before handing the current buffer to XDP or to the skb. If the allocation fails there, drop the packet and return the still-owned current buffer to BM, preserving the pool depth. Once the refill succeeds, later local drops retire/free the current buffer instead of returning it to BM. Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support") Fixes: d6526926de73 ("net: mvpp2: fix memory leak in mvpp2_rx") Signed-off-by: Til Kaiser <mail@tk154.de> Link: https://patch.msgid.link/20260607134943.21996-4-mail@tk154.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-11net: mvpp2: limit XDP frame size to the RX bufferTil Kaiser
mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet. Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support") Signed-off-by: Til Kaiser <mail@tk154.de> Link: https://patch.msgid.link/20260607134943.21996-3-mail@tk154.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-11net: mvpp2: sync RX data at the hardware packet offsetTil Kaiser
mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware. Fixes: e1921168bbd4 ("mvpp2: sync only the received frame") Signed-off-by: Til Kaiser <mail@tk154.de> Link: https://patch.msgid.link/20260607134943.21996-2-mail@tk154.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-11kbuild: rust: clean `zerocopy-derive` in `mrproper`Miguel Ojeda
Just like for the other two Rust proc macros, remove the artifacts in `mrproper`. This should have been part of commit 506054980429 ("rust: zerocopy-derive: enable support in kbuild"). Link: https://patch.msgid.link/20260610143025.368801-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-06-11ALSA: usb-audio: Use the new helper for shutdown refcountTakashi Iwai
Replace the open-code for managing the shutdown refcount with the new helpers. Only a code cleanup, no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260610154538.51076-6-tiwai@suse.de
2026-06-11ALSA: aloop: Use the new helper for stop-count refcountTakashi Iwai
Replace the open-code for managing the stop-count refcount with the new helpers. Only a code cleanup, no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260610154538.51076-5-tiwai@suse.de
2026-06-11ALSA: hda: Use the new helper for PCM instance refcountTakashi Iwai
HD-audio core driver has some open-code for managing the refcount for PCM instances, and it can be replaced gracefully with the new helpers. Only a code cleanup, no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260610154538.51076-4-tiwai@suse.de
2026-06-11ALSA: core: Use the new helper for the power refcountTakashi Iwai
Replace the open code for managing the power refcount in the snd_card object with the new helper functions. Only a code cleanup, no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260610154538.51076-3-tiwai@suse.de
2026-06-11ALSA: Add simple refcount helper functionsTakashi Iwai
There are many open-code to manage the same pattern for refcount + wakeup sync at closing. Let's provide the common helper functions to replace the open-code. - The recount is kept in struct snd_refcount, where it's initialized by snd_refcount_init(). - The user can simply reference or unreference via snd_refcount_get() and snd_refcount_put() functions - The user can wait for the all usages gone by snd_refcount_sync() Note that here we use atomic_t instead of refcount_t since the current users allow reusing the refcount after sync again. The design of refcount_t prevents exactly this behavior, so it doesn't fit. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260610154538.51076-2-tiwai@suse.de
2026-06-11mtd: cfi: Use common error handling code in two functionsMarkus Elfring
Use additional labels so that a bit of exception handling can be better reused at the end of two function implementations. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-06-11mtd: slram: simplify register_device() cleanupRuoyu Wang
Use local variables for the list entry, mtd_info, and private data while initializing a new device. This keeps the initialization path easier to read and publishes the new list entry only after mtd_device_register() has succeeded. Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-06-11mtd: slram: remove failed entries from the device listRuoyu Wang
register_device() links a new slram_mtdlist entry before allocating all of the state needed by the entry. If a later allocation, memremap(), or mtd_device_register() fails, the partially initialized entry remains on the global list. A later cleanup can then dereference or free invalid state from that failed entry. Unwind the partially initialized entry and clear the list tail on each failure path after the entry has been linked. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-06-11mtd: rawnand: ndfc: use ioread32be/iowrite32be and allow COMPILE_TESTRosen Penev
Replace ppc4xx-specific in_be32/out_be32 with generic ioread32be/ iowrite32be to make the driver portable. Add COMPILE_TEST dependency to get build coverage on non-ppc4xx architectures. While at it, replace 4xx with 44x. The latter was removed a while ago and is only kept for compatibility. Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-06-11MAINTAINERS: expand Lynx 28G entry to cover Lynx 10G SerDesVladimir Oltean
The lynx-28g and lynx-10g drivers share code and hardware architecture, so let them be covered by a single MAINTAINERS entry. Add myself as a second maintainer alongside Ioana Ciornei. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-17-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-10g: new driverVladimir Oltean
Introduce a driver for the networking lanes of the 10G Lynx SerDes block, present on the majority of Layerscape and QorIQ (Freescale/NXP) SoCs. As with the 28G Lynx, the SerDes lanes come pre-initialized out of reset and the consumers use them that way outside the Generic PHY framework (for networking, the static configuration remains for the entire SoC lifetime, whereas for SATA and PCIe, the hardware reconfigures itself automatically for other link speeds). The need for the Generic PHY framework comes specifically for networking use cases where a static lane configuration is not sufficient. For example a network MAC is connected to an SFP cage, where various SFP or SFP+ modules can be connected. Each of them may require a different SerDes protocol (SGMII, 1000Base-X, 10GBase-R), which phylink + sfp-bus are responsible of figuring out. The phylink drivers are: - enetc - felix - dpaa_eth (fman_memac) - dpaa2-eth - dpaa2-switch and they all need to reconfigure the SerDes for the requested link mode, using phy_set_mode_ext() (and phy_validate() to see if it is supported in the first place). Note that SerDes 2 on LS1088A is exclusively non-networking, so there is currently no need for this driver. Therefore we skip matching on its compatible string and do not probe on that device. Co-developed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-16-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dt-bindings: phy: lynx-10g: initial documentVladimir Oltean
Add a schema for the 10G Lynx SerDes. This is very similar to the modern form of the 28G Lynx SerDes, which is very much the intention. There is intentionally no generic fsl,lynx-10g compatible string due to the hardware inability to report its capabilities, despite having a common register map. We allow both forms of #phy-cells = <1> in the top-level provider and #phy-cells = <0> in the per-lane provider for more flexibility to consumers, and because the kernel code is shared with the 28G Lynx which already has that support for compatibility reasons. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260610151952.2141019-15-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: improve phy_validate() procedureVladimir Oltean
lynx_28g_validate() suffers from the following shortcomings: - Changing the protocol should not be possible if the source protocol of the lane is unsupported. This is because lynx_28g_proto_conf[] only covers the register deltas between any pair of supported lane modes, but that delta is probably incomplete if the source protocol is, say, PCIe (which is currently assimilated by the driver to LANE_MODE_UNKNOWN). lynx_28g_proto_conf() does refuse changing the protocol if the current one is unsupported, but we shouldn't advertise it via phy_validate() at all. The phy_set_mode_ext() call should perform the exact same verifications as phy_validate() did, in case the caller bypassed phy_validate(). So we need to centralize the logic into a common validation. But lynx_28g_set_mode() later needs the lane_mode that this validation needs to compute anyway, so name the common helper lynx_phy_mode_to_lane_mode() and let it return that lane_mode. - Future core sanity checks on phy_validate() will want to differentiate the case where this optional method is not implemented from the case where the mode/submode is really not supported. So we shouldn't return -EOPNOTSUPP from lynx_28g_validate(), but -EINVAL to signal that we do implement the operation: https://lore.kernel.org/linux-phy/aY2lFTIALH7qEJmM@shell.armlinux.org.uk/ Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-14-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: optimize read-modify-write operationVladimir Oltean
It is unnecessary to rewrite a register if the masked field already contains the desired value upon reading. The hardware behaviour does not depend upon register writes with identical values. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-13-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: add support for big endian register mapsVladimir Oltean
Some 10G Lynx SerDes blocks are big endian and require byte swapping because the CPUs are little endian armv8 (LS1046A). Parse the "big-endian" device tree property, and modify the base lynx_read() and lynx_write() accessors to test this property before issuing either the ioread32() or ioread32be() variants (as per Documentation/driver-api/device-io.rst). All other accessors - lynx_rmw(), lynx_lane_read(), lynx_lane_write(), lynx_lane_rmw(), lynx_pll_read() - need to go through these endian-aware helpers. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-12-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: common probe() and remove()Vladimir Oltean
Factor the device-agnostic logic from lynx_28g_probe() and lynx_28g_remove() into lynx_probe() and lynx_remove() inside phy-fsl-lynx-core.c. These will be shared with the 10G Lynx driver. Since the PLL configuration, lane configuration and CDR lock detection procedure are going to be different, introduce lynx_info function pointers so that this code remains in the 28G Lynx driver. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-11-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: make lynx_28g_pll_read_configuration() callable per PLLVladimir Oltean
In a future change, lynx_28g_pll_read_configuration() and lynx_28g_lane_read_configuration() will be made methods of struct lynx_info. There is no functional reason, but lynx_28g_lane_read_configuration() is called per lane and lynx_28g_pll_read_configuration() iterates over PLLs internally. So the API exported by the lynx_info structure would not be uniform. Change lynx_28g_pll_read_configuration() to also permit reading the PLL configuration individually, and move the for loop at the call site. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-10-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: move struct lynx_info definitions downwardsVladimir Oltean
We need to be able to reference more function pointers in upcoming patches. The struct lynx_info definitions are currently placed a bit up in lynx-28g.c in order to be able to do that without function prototype forward declarations, so move them downward to avoid that situation. No functional change intended. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-9-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: provide default lynx_lane_supports_mode() implementationVladimir Oltean
For the 28G Lynx, there are situations where a protocol is not supported on a lane despite there being a PCCR register and protocol converter available: - LX2160A SerDes 1: reference manual documents PCCD fields E25GC_CFG and E25GD_CFG and protocol converter registers E25GCCR1..E25GCCR3 / E25GDCR1..E25GDCR3, but nonetheless, Table 289. SerDes 1 protocol mapping shows no RCW[SRDS_PRTCL_S1] value for which lanes C and D support 25G - when using the "fsl,lynx-28g" fallback compatible string, we don't want to offer 25GbE because we don't know if the lane supports it, even though we know how to reach the PCCR and protocol converter registers for it. But for the upcoming 10G Lynx SerDes, the above situations don't exist. There, if we know how to reach the PCCR and protocol converter registers on a lane, we implicitly know that the protocol is supported there, so implementing priv->info->lane_supports_mode() would be redundant. Implement lynx_lane_supports_mode_default() which decides whether a lane mode is supported just based on priv->info->get_pccr() and priv->info->get_pcvt_offset(). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-8-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: generalize protocol converter accessorsVladimir Oltean
The protocol converters on the 10G Lynx are architecturally similar, but different in layout from the 28G Lynx ones. Move lynx_pccr_read(), lynx_pccr_write(), lynx_pcvt_read() and lynx_pcvt_write() from the 28G Lynx driver to the common module, and permit each SerDes driver to provide just its own bits in order to use this common API. Currently, that just means that the direct calls to lynx_28g_get_pcvt_offset() are modified to go through the lynx->info->get_pcvt_offset() indirect function call, and similarly, lynx_28g_get_pccr() through lynx->info->get_pccr(). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-7-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: common lynx_pll_get()Vladimir Oltean
The logic should be absolutely unchanged in the new 10G Lynx SerDes driver, so let's move this to phy-fsl-lynx-core.c and update the 28G Lynx driver to use the common variant. While at it, update the call site, lynx_28g_lane_remap_pll(), to use the new data structures, and refactor the NULL pll pointer check (the current form triggers a checkpatch CHECK). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-6-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: move data structures to coreVladimir Oltean
The goal is to avoid duplicating the core data structures when introducing the new lynx-10g driver. We move the following to phy-fsl-lynx-core: - struct lynx_28g_pll -> struct lynx_pll. This has some hardware-specific register fields which need to become hardware agnostic (the PLL register layout is different for Lynx 10G), So: - PLLnRSTCTL_DIS(pll->rstctl) becomes !pll->enabled - PLLnRSTCTL_LOCK(pll->rstctl) becomes pll->locked - FIELD_GET(PLLnCR1_FRATE_SEL, pll->cr1) becomes pll->frate_sel - FIELD_GET(PLLnCR0_REFCLK_SEL, pll->cr0) becomes pll->refclk_sel - struct lynx_28g_lane -> struct lynx_lane - struct lynx_28g_priv -> struct lynx_priv - field lane[LYNX_28G_NUM_LANE] has to be dynamically allocated. Not all Lynx 10G SerDes blocks have 8 lanes. - LYNX_28G_NUM_PLL -> LYNX_NUM_PLL. This is an architectural constant which is the same for Lynx 10G as well. To avoid major noise in the lynx-28g driver, we keep compatibility shims (for now) where the old lynx_28g names are preserved, but translate to the common data structures. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-5-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: move lane mode helpers to new core moduleVladimir Oltean
Do some preparation work for the introduction of the lynx-10g driver, which will share a common backbone with the 28G Lynx SerDes. This is just trivial stuff which can be moved without any surgery, and is easy to follow but otherwise pollutes more serious changes. The lane modes themselves are exported to a public header, because on the 10G Lynx, the hardware requires implementing a procedure called "RCW override". This requires coordination with drivers/soc/fsl/guts.c to tell it that a SerDes lane needs to be switched to a different protocol (enum lynx_lane_mode). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-4-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: reject probing on devices with unsupported OF nodesVladimir Oltean
It is possible to bind the lynx-28g driver to an arbitrary device with an OF node, using the driver_override mechanism that is available for the platform bus, and trigger a crash this way: $ echo 1ea0000.serdes > /sys/bus/platform/drivers/lynx-10g/unbind $ echo lynx-28g > /sys/bus/platform/devices/1ea0000.serdes/driver_override $ echo 1ea0000.serdes > /sys/bus/platform/drivers/lynx-28g/bind Internal error: Oops: 0000000096000004 [#1] SMP Hardware name: LS1028A RDB Board (DT) pc : lynx_probe+0x118/0x4fc lr : lynx_probe+0x110/0x4fc Call trace: lynx_probe+0x118/0x4fc (P) lynx_28g_probe+0x54/0x7c platform_probe+0x68/0xa4 really_probe+0x14c/0x2ec __driver_probe_device+0xc8/0x170 device_driver_attach+0x58/0xa8 bind_store+0xd8/0x118 drv_attr_store+0x24/0x38 The crash is caused by the fact that of_device_get_match_data() returns NULL (the bound device has a different compatible string) and this is not checked. There was a previous attempt to avoid this in commit c9d80e861034 ("phy: lynx-28g: require an OF node to probe"), but the mechanism was not fully understood and it only covered the case where the driver was bound to a device with no OF node. The issue was found during Sashiko review. Elevated privilege is required to override the driver for a device, so the real life impact of the issue should not be very high. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-3-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: avoid returning NULL in of_xlate() functionVladimir Oltean
Sashiko points out that _of_phy_get() does not support a NULL returned output from phy_provider->of_xlate(), just a valid pointer or a pointer-encoded error. When lynx_28g_probe() -> for_each_available_child_of_node() skips over lanes which have OF nodes with status = "disabled", the priv->lane[idx].phy pointer will remain NULL. This NULL pointer may be propagated to lynx_28g_xlate() if the device tree contains a phandle to the disabled lane AND fw_devlink did not block probing for the consumer. In that case, the PHY core will crash when trying to dereference the NULL phy pointer. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-2-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dt-bindings: PCI: mediatek: Add support for EcoNet EN7528Caleb James DeLisle
Introduce EcoNet EN7528 SoC compatible in MediaTek PCIe controller binding. EcoNet PCIe controller has the same configuration model as Mediatek v2 but is initialized more similarly to an MT7621 PCIe. Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260521171951.1495781-3-cjd@cjdns.fr
2026-06-11PCI: mediatek: Use actual physical address instead of virt_to_phys()Manivannan Sadhasivam
The driver previously used virt_to_phys() on the ioremapped register base (port->base) to compute the MSI message address. Using virt_to_phys() on an IO mapped address is incorrect because it expects a kernel virtual address. To fix it, store the physical start of the I/O register region in mtk_pcie_port->phys_base and use it to build the MSI address. This replaces the incorrect virt_to_phys() usage and ensures MSI addresses are generated correctly. Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Caleb James DeLisle <cjd@cjdns.fr> Link: https://patch.msgid.link/20260521171951.1495781-2-cjd@cjdns.fr
2026-06-11phy: qcom: qmp-pcie: Add QMP PCIe PHY support for ElizaKrishna Chaitanya Chundru
Add QMP PCIe PHY support for the Eliza SoC. Introduce a new Gen3x1 PHY configuration with Eliza-specific initialization tables, and reuse the existing sm8550 Gen3x2 configuration for the Gen3x2 PHY instance. Also add the missing QPHY_PCIE_V6_PCS_PCIE_INT_AUX_CLK_CONFIG1 register definition to the PCIe V6 PCS header. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260608-eliza-v3-3-9bdeb7434b28@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dt-bindings: phy: sc8280xp-qmp-pcie: Document Eliza PCIe phyKrishna Chaitanya Chundru
Add compatibles for the Eliza PCIe QMP PHY's, which supports Gen3x1 and Gen3x2 configurations. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260608-eliza-v3-1-9bdeb7434b28@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: nxp-ptn3222: Use named initializers for struct i2c_device_idUwe Kleine-König (The Capable Hub)
While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/20260519151957.1593214-2-u.kleine-koenig@baylibre.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on PurwaKonrad Dybcio
Neither of the two Gen4x4 PHYs found on Purwa supports bifurcation. The PHY is however physically laid out as if it were to, since there are two separate ports (A/B). Split out a new if-then block to un-require the bifurcation register handle to squash this warning: purwa-iot-evk.dtb: phy@1bd4000 (qcom,x1p42100-qmp-gen4x4-pcie-phy): 'qcom,4ln-config-sel' is a required property Fixes: 2e1ffd4c1805 ("dt-bindings: phy: qcom,qmp-pcie: Add X1P42100 PCIe Gen4x4 PHY") Reported-by: Rob Herring <robh@kernel.org> Closes: https://lore.kernel.org/linux-arm-msm/176857775469.1631885.16133311938753588148.robh@kernel.org/ Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260610-topic-purwa_phy_shutup_warning-v2-1-951c1fbfe9b2@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-07-29 06:44:01 +0000