mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-10 20:48:12 +00:00
No description
- C 96.8%
- Assembly 0.9%
- Rust 0.7%
- Shell 0.6%
- Python 0.5%
- Other 0.3%
9d146a5d10
Jacob Keller says: ==================== Intel Wired LAN Driver Updates 2026-04-20 (ice) Since this is a set of related fixes for just the ice driver, Jake provides the following description for the series: We recently ran into a nasty corner case issue with a customer operating E825C cards seeing some strange behavior with missing Tx timestamps. During the course of debugging. This series contains a few fixes found during this debugging process. The primary issue discovered in the investigation is a misconfiguration of the E825C PHY timestamp interrupt register, PHY_REG_TS_INT_CONFIG. This register is responsible for programming the Tx timestamp behavior of a PHY port. The driver programs two values here: a threshold for when to interrupt and whether the interrupt is enabled. The threshold value is used by hardware to determine when to trigger a Tx timestamp interrupt. The interrupt cause for the port is raised when the number of outstanding timestamps in the PHY port timestamp memory meets the threshold. The interrupt cause is not cleared until the number of outstanding timestamps drops *below* the threshold. It is considered a misconfiguration if the threshold is programmed to 0. If the interrupt is enabled while the threshold is zero, hardware will raise the interrupt cause at the next time it checks. Once raised, the interrupt cause for the port will never lower, since you cannot have fewer than zero outstanding timestamps. Worse, the timestamp status for the port will remain high even if the PHY_REG_TS_INT_CONFIG is reprogrammed with a new threshold. The PHY is a separate hardware block from the MAC, and thus the interrupt status for the port will remain high even if you reset the device MAC with a PF reset, CORE reset, or GLOBAL reset. PHY ports are connected together into quads. Each quad muxes the PHY interrupt status for the 4 ports on the quad together before connecting that to the MACs miscellaneous interrupt vector. As a result, if a single PHY port in the quad is stuck, no timestamp interrupts will be generated for any timestamp on any port on that quad. The ice driver never directly writes a value of 0 for the threshold. Indeed, the desired behavior is to set the threshold to 1, so that interrupts are generated as soon as a single timestamp is captured. Unfortunately, it turns out that for the E825C PHY, programming the threshold and enable bit in the same write may cause a race in the PHY timestamp block. The PHY may "see" the interrupt as enabled first before it sees the threshold value. If the previous threshold value is zero (such as when the register is initialized to zero at a cold power on), the hardware may race with programming the threshold and set the PHY interrupt status to high as described above. The first patch in this series corrects that programming order, ensuring that the threshold is always written first in a separate transaction from enabling the interrupt bit. Additionally, an explicit check against writing a 0 is added to make it clear to future readers that writing 0 to the threshold while enabling the interrupt is not safe. The PHY timestamp block does not reset with the MAC, and seems to only reset during cold power on. This makes recovery from the faulty configuration difficult. To address this, perform an explicit reset of the PHY PTP block during initialization. This is achieved by writing the PHY_REG_GLOBAL register. This performs a PHY soft reset, which completely resets the timestamp block. This includes clearing the timestamp memory, the PHY timestamp interrupt status, and the PHY PTP counter. A soft reset of all ports on the device is done as part of ice_ptp_init_phc() during early initialization of the PTP functionality by the PTP clock owner, prior to programming each PHY. The ice_ptp_init_phc() function is called at driver init and during reinitialization after all forms of device reset. This ensures that the driver begins operation at a clean slate, rather than carrying over the stale and potentially buggy configuration of a previous driver. While attempting to root cause the issue with the PHY timestamp interrupt, we also discovered that the driver incorrectly assumes that it is operating on E822 hardware when reading the PHY timestamp memory status registers in a few places. This includes the check at the end of the interrupt handler, as well as the check done inside the PTP auxiliary function. This prevented the driver from detecting waiting timestamps on ports other than the first two. Finally, the ice_ptp_read_tx_hwstamp_status_eth56g() function was discovered to only read the timestamp interrupt status value from the first quad due to mistaking the port index for a PHY quad index. This resulted in reporting the timestamp status for the second quad as identical to the first quad instead of properly reporting its value. This is a minor fix since the function currently is only used for diagnostic purposes and does not impact driver decision logic. ==================== Link: https://patch.msgid.link/20260420-jk-iwl-net-2026-04-20-ptp-e825c-phy-interrupt-fixes-v1-0-bc2240f42251@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
History
|
|
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| io_uring | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| rust | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .clippy.toml | ||
| .cocciconfig | ||
| .editorconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .pylintrc | ||
| .rustfmt.toml | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel ============ The Linux kernel is the core of any Linux operating system. It manages hardware, system resources, and provides the fundamental services for all other software. Quick Start ----------- * Report a bug: See Documentation/admin-guide/reporting-issues.rst * Get the latest kernel: https://kernel.org * Build the kernel: See Documentation/admin-guide/quickly-build-trimmed-linux.rst * Join the community: https://lore.kernel.org/ Essential Documentation ----------------------- All users should be familiar with: * Building requirements: Documentation/process/changes.rst * Code of Conduct: Documentation/process/code-of-conduct.rst * License: See COPYING Documentation can be built with make htmldocs or viewed online at: https://www.kernel.org/doc/html/latest/ Who Are You? ============ Find your role below: * New Kernel Developer - Getting started with kernel development * Academic Researcher - Studying kernel internals and architecture * Security Expert - Hardening and vulnerability analysis * Backport/Maintenance Engineer - Maintaining stable kernels * System Administrator - Configuring and troubleshooting * Maintainer - Leading subsystems and reviewing patches * Hardware Vendor - Writing drivers for new hardware * Distribution Maintainer - Packaging kernels for distros * AI Coding Assistant - LLMs and AI-powered development tools For Specific Users ================== New Kernel Developer -------------------- Welcome! Start your kernel development journey here: * Getting Started: Documentation/process/development-process.rst * Your First Patch: Documentation/process/submitting-patches.rst * Coding Style: Documentation/process/coding-style.rst * Build System: Documentation/kbuild/index.rst * Development Tools: Documentation/dev-tools/index.rst * Kernel Hacking Guide: Documentation/kernel-hacking/hacking.rst * Core APIs: Documentation/core-api/index.rst Academic Researcher ------------------- Explore the kernel's architecture and internals: * Researcher Guidelines: Documentation/process/researcher-guidelines.rst * Memory Management: Documentation/mm/index.rst * Scheduler: Documentation/scheduler/index.rst * Networking Stack: Documentation/networking/index.rst * Filesystems: Documentation/filesystems/index.rst * RCU (Read-Copy Update): Documentation/RCU/index.rst * Locking Primitives: Documentation/locking/index.rst * Power Management: Documentation/power/index.rst Security Expert --------------- Security documentation and hardening guides: * Security Documentation: Documentation/security/index.rst * LSM Development: Documentation/security/lsm-development.rst * Self Protection: Documentation/security/self-protection.rst * Reporting Vulnerabilities: Documentation/process/security-bugs.rst * CVE Procedures: Documentation/process/cve.rst * Embargoed Hardware Issues: Documentation/process/embargoed-hardware-issues.rst * Security Features: Documentation/userspace-api/seccomp_filter.rst Backport/Maintenance Engineer ----------------------------- Maintain and stabilize kernel versions: * Stable Kernel Rules: Documentation/process/stable-kernel-rules.rst * Backporting Guide: Documentation/process/backporting.rst * Applying Patches: Documentation/process/applying-patches.rst * Subsystem Profile: Documentation/maintainer/maintainer-entry-profile.rst * Git for Maintainers: Documentation/maintainer/configure-git.rst System Administrator -------------------- Configure, tune, and troubleshoot Linux systems: * Admin Guide: Documentation/admin-guide/index.rst * Kernel Parameters: Documentation/admin-guide/kernel-parameters.rst * Sysctl Tuning: Documentation/admin-guide/sysctl/index.rst * Tracing/Debugging: Documentation/trace/index.rst * Performance Security: Documentation/admin-guide/perf-security.rst * Hardware Monitoring: Documentation/hwmon/index.rst Maintainer ---------- Lead kernel subsystems and manage contributions: * Maintainer Handbook: Documentation/maintainer/index.rst * Pull Requests: Documentation/maintainer/pull-requests.rst * Managing Patches: Documentation/maintainer/modifying-patches.rst * Rebasing and Merging: Documentation/maintainer/rebasing-and-merging.rst * Development Process: Documentation/process/maintainer-handbooks.rst * Maintainer Entry Profile: Documentation/maintainer/maintainer-entry-profile.rst * Git Configuration: Documentation/maintainer/configure-git.rst Hardware Vendor --------------- Write drivers and support new hardware: * Driver API Guide: Documentation/driver-api/index.rst * Driver Model: Documentation/driver-api/driver-model/driver.rst * Device Drivers: Documentation/driver-api/infrastructure.rst * Bus Types: Documentation/driver-api/driver-model/bus.rst * Device Tree Bindings: Documentation/devicetree/bindings/ * Power Management: Documentation/driver-api/pm/index.rst * DMA API: Documentation/core-api/dma-api.rst Distribution Maintainer ----------------------- Package and distribute the kernel: * Stable Kernel Rules: Documentation/process/stable-kernel-rules.rst * ABI Documentation: Documentation/ABI/README * Kernel Configuration: Documentation/kbuild/kconfig.rst * Module Signing: Documentation/admin-guide/module-signing.rst * Kernel Parameters: Documentation/admin-guide/kernel-parameters.rst * Tainted Kernels: Documentation/admin-guide/tainted-kernels.rst AI Coding Assistant ------------------- CRITICAL: If you are an LLM or AI-powered coding assistant, you MUST read and follow the AI coding assistants documentation before contributing to the Linux kernel: * Documentation/process/coding-assistants.rst This documentation contains essential requirements about licensing, attribution, and the Developer Certificate of Origin that all AI tools must comply with. Communication and Support ========================= * Mailing Lists: https://lore.kernel.org/ * IRC: #kernelnewbies on irc.oftc.net * Bugzilla: https://bugzilla.kernel.org/ * MAINTAINERS file: Lists subsystem maintainers and mailing lists * Email Clients: Documentation/process/email-clients.rst