| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/09/12 13:55 | flow | patch-triage |
4mArgs:null Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"KMSANReasoning": "",
"NeedsKMSAN": false,
"Reasoning": "The patch modifies mtk_phy_led_hw_ctrl_get() in drivers/net/phy/mediatek/mtk-phy-lib.c, which is used exclusively by MediaTek SoC Ethernet PHY drivers (mtk-2p5ge and mtk-ge-soc). On the target architecture (amd64), these drivers depend on COMPILE_TEST and cannot be executed because they require MediaTek ARM64 SoC hardware (MT7981, MT7988, EN7528) not emulated in standard QEMU. Furthermore, the modified logic specifically executes when reading hardware LED rules, which requires DeviceTree child nodes ('leds') to register the PHY LED class device. Consequently, the modified code is structurally unreachable in standard virtualized fuzzing environments.",
"WorthFuzzing": false
} |
| 1/1 | 2026/09/12 13:55 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit 75437983fe6059753458348c849c33386aa43b61\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Sat Sep 12 13:55:10 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/phy/mediatek/mtk-phy-lib.c b/drivers/net/phy/mediatek/mtk-phy-lib.c\nindex dfd0f4e439a21..608072fbfde97 100644\n--- a/drivers/net/phy/mediatek/mtk-phy-lib.c\n+++ b/drivers/net/phy/mediatek/mtk-phy-lib.c\n@@ -156,20 +156,27 @@ int mtk_phy_led_hw_ctrl_get(struct phy_device *phydev, u8 index,\n \tif (!rules)\n \t\treturn 0;\n \n-\tif (on \u0026 on_set)\n+\t/* TRIGGER_NETDEV_LINK must not be reported together with any of the\n+\t * per-speed rules, the netdev trigger rejects that combination.\n+\t * on_set holds every speed this LED can indicate and is what\n+\t * mtk_phy_led_hw_ctrl_set() programs for TRIGGER_NETDEV_LINK, so\n+\t * report the speed independent rule only when they are all on.\n+\t */\n+\tif ((on \u0026 on_set) == on_set) {\n \t\t*rules |= BIT(TRIGGER_NETDEV_LINK);\n+\t} else {\n+\t\tif (on \u0026 MTK_PHY_LED_ON_LINK10)\n+\t\t\t*rules |= BIT(TRIGGER_NETDEV_LINK_10);\n \n-\tif (on \u0026 MTK_PHY_LED_ON_LINK10)\n-\t\t*rules |= BIT(TRIGGER_NETDEV_LINK_10);\n+\t\tif (on \u0026 MTK_PHY_LED_ON_LINK100)\n+\t\t\t*rules |= BIT(TRIGGER_NETDEV_LINK_100);\n \n-\tif (on \u0026 MTK_PHY_LED_ON_LINK100)\n-\t\t*rules |= BIT(TRIGGER_NETDEV_LINK_100);\n+\t\tif (on \u0026 MTK_PHY_LED_ON_LINK1000)\n+\t\t\t*rules |= BIT(TRIGGER_NETDEV_LINK_1000);\n \n-\tif (on \u0026 MTK_PHY_LED_ON_LINK1000)\n-\t\t*rules |= BIT(TRIGGER_NETDEV_LINK_1000);\n-\n-\tif (on \u0026 MTK_PHY_LED_ON_LINK2500)\n-\t\t*rules |= BIT(TRIGGER_NETDEV_LINK_2500);\n+\t\tif (on \u0026 MTK_PHY_LED_ON_LINK2500)\n+\t\t\t*rules |= BIT(TRIGGER_NETDEV_LINK_2500);\n+\t}\n \n \tif (on \u0026 MTK_PHY_LED_ON_FDX)\n \t\t*rules |= BIT(TRIGGER_NETDEV_FULL_DUPLEX);\n"
} |
| 2/1 | 2026/09/12 13:55 | agent | patch-evaluator |
4mModel:core Args: null Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"Reasoning": "The patch modifies mtk_phy_led_hw_ctrl_get() in drivers/net/phy/mediatek/mtk-phy-lib.c, which is used exclusively by MediaTek SoC Ethernet PHY drivers (mtk-2p5ge and mtk-ge-soc). On the target architecture (amd64), these drivers depend on COMPILE_TEST and cannot be executed because they require MediaTek ARM64 SoC hardware (MT7981, MT7988, EN7528) not emulated in standard QEMU. Furthermore, the modified logic specifically executes when reading hardware LED rules, which requires DeviceTree child nodes ('leds') to register the PHY LED class device. Consequently, the modified code is structurally unreachable in standard virtualized fuzzing environments.",
"WorthFuzzing": false
}Instruction: You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.
IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.
================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.
- REACHABILITY IS THE PRIMARY GATE:
Fuzzing can only discover bugs in code that can actually execute in standard virtualized
environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
regardless of whether it adds assertions or complex logic.
- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
Patch authors routinely label changes as "cleanups", "refactorings", or state
"No functional change intended". Do NOT take these claims at face value.
Code refactorings that rearrange logic, introduce helper functions, or alter state management
in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
If reachable executable code is modified or refactored, it MUST be fuzzed.
- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
Even if the author believes the invariant always holds, fuzzing is essential to verify whether
an unusual sequence of operations can violate it.
================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:
- Non-kernel and non-executable changes:
* Modifications to Documentation/, comments, or spelling fixes.
* User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
that do not affect the compiled kernel image (vmlinux) or kernel modules.
* Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
that do not alter control flow or data structures.
* Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
* Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
* Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
physical PCI hot-unplug or manual sysfs driver unbinding.
* Code paths exclusive to architectures other than the target architecture.
================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
* Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
* Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
* Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
* Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).
================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:
- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
Do NOT list generic, ubiquitous functions called by almost every program in the corpus
(including, but not limited to: general memory allocators and deallocators, page fault
and trap handlers, or core synchronization primitives; this is not an exhaustive list).
Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
which severely dilutes fuzzing effort away from the actual changes.
- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
List functions that specifically implement the logic being added or altered, or direct API entrypoints
for the subsystem feature under review.
- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).
================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.
Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.
Prompt: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit 75437983fe6059753458348c849c33386aa43b61
Author: syz-cluster <triage@syzkaller.com>
Date: Sat Sep 12 13:55:10 2026 +0000
syz-cluster: applied patch under review
diff --git a/drivers/net/phy/mediatek/mtk-phy-lib.c b/drivers/net/phy/mediatek/mtk-phy-lib.c
index dfd0f4e439a21..608072fbfde97 100644
--- a/drivers/net/phy/mediatek/mtk-phy-lib.c
+++ b/drivers/net/phy/mediatek/mtk-phy-lib.c
@@ -156,20 +156,27 @@ int mtk_phy_led_hw_ctrl_get(struct phy_device *phydev, u8 index,
if (!rules)
return 0;
- if (on & on_set)
+ /* TRIGGER_NETDEV_LINK must not be reported together with any of the
+ * per-speed rules, the netdev trigger rejects that combination.
+ * on_set holds every speed this LED can indicate and is what
+ * mtk_phy_led_hw_ctrl_set() programs for TRIGGER_NETDEV_LINK, so
+ * report the speed independent rule only when they are all on.
+ */
+ if ((on & on_set) == on_set) {
*rules |= BIT(TRIGGER_NETDEV_LINK);
+ } else {
+ if (on & MTK_PHY_LED_ON_LINK10)
+ *rules |= BIT(TRIGGER_NETDEV_LINK_10);
- if (on & MTK_PHY_LED_ON_LINK10)
- *rules |= BIT(TRIGGER_NETDEV_LINK_10);
+ if (on & MTK_PHY_LED_ON_LINK100)
+ *rules |= BIT(TRIGGER_NETDEV_LINK_100);
- if (on & MTK_PHY_LED_ON_LINK100)
- *rules |= BIT(TRIGGER_NETDEV_LINK_100);
+ if (on & MTK_PHY_LED_ON_LINK1000)
+ *rules |= BIT(TRIGGER_NETDEV_LINK_1000);
- if (on & MTK_PHY_LED_ON_LINK1000)
- *rules |= BIT(TRIGGER_NETDEV_LINK_1000);
-
- if (on & MTK_PHY_LED_ON_LINK2500)
- *rules |= BIT(TRIGGER_NETDEV_LINK_2500);
+ if (on & MTK_PHY_LED_ON_LINK2500)
+ *rules |= BIT(TRIGGER_NETDEV_LINK_2500);
+ }
if (on & MTK_PHY_LED_ON_FDX)
*rules |= BIT(TRIGGER_NETDEV_FULL_DUPLEX);
|
| 3/2 | 2026/09/12 13:55 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 3364 output: 26 thoughts: 104 Thoughts: **Analyzing a MediaTek PHY Driver Patch** Okay, so this patch hits `drivers/net/phy/mediatek/mtk-phy-lib.c`, specifically the `mtk_phy_led_hw_ctrl_get` function. Right away, my expert intuition tells me to zoom out. I need to understand the larger context. Is this file a MediaTek-specific PHY driver library? Given the path, it looks highly likely, but confirmation is always best. I'm going to quickly check the surrounding directory, `drivers/net/phy/mediatek/`, to confirm. I'll probably use my preferred tooling for this – codesearch, a `read-file` command, or maybe even just a quick grep – to get a better feel for the structure and purpose of this library. Understanding the scope and intent here is critical before digging into the code change itself. I want to see how `mtk-phy-lib.c` fits into the Mediatek PHY ecosystem before I start looking at the specific function modification. |
| 4/2 | 2026/09/12 13:55 | tool | codesearch-dir-index |
0mArgs:{
"Dir": "drivers/net/phy/mediatek"
}Results: {
"Files": [
"mtk-2p5ge.c",
"mtk-fe-soc.c",
"mtk-ge-soc.c",
"mtk-ge.c",
"mtk-phy-lib.c",
"mtk.h"
],
"Subdirs": null
} |
| 5/2 | 2026/09/12 13:55 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 3787 output: 31 thoughts: 28 Thoughts: Here's my attempt at summarizing the thought process, as if I were having it: **Digging into Mediatek PHY Kconfig** Okay, so I need to understand the configuration options for the Mediatek PHY drivers. My first instinct, and where I *always* start with these things, is the Kconfig file. I'm assuming it's structured in the standard way, so I'm going to look for it under `drivers/net/phy/mediatek` first. That would be the ideal place, a dedicated directory for that specific driver. If it's not there, the next logical place would be the main `drivers/net/phy/Kconfig` file. That's the fallback - hopefully it's not a generic entry. Let's see what's in those files. |
| 6/2 | 2026/09/12 13:55 | tool | grepper |
0mArgs:{
"Expression": "mtk-phy-lib",
"PathPrefix": "drivers/net/phy"
}Results: {
"Output": "drivers/net/phy/mediatek/Makefile=5=obj-$(CONFIG_MEDIATEK_GE_SOC_PHY)\t+= mtk-ge-soc.o\ndrivers/net/phy/mediatek/Makefile:6:obj-$(CONFIG_MTK_NET_PHYLIB)\t\t+= mtk-phy-lib.o\n"
} |
| 7/2 | 2026/09/12 13:55 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 4108 output: 32 thoughts: 21 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience: **Investigating `CONFIG_MTK_NET_PHYLIB` Definition in Kconfig** Okay, so I need to track down where `CONFIG_MTK_NET_PHYLIB` is defined. This likely means navigating the Kconfig files within the relevant Mediatek network driver codebase. My first instinct is to use `grep` or a similar tool to search the Kconfig files directly. I'll need to remember to look in the architecture-specific directories and any common network infrastructure directories within the build system. This isn't usually a simple grep, I expect to do some targeted searching to narrow down the relevant files. Once I find the definition, I'll need to understand its context: what dependencies are in place, what other related symbols are configured nearby, and what the help text says. Understanding the dependencies is critical to troubleshooting anything related to this config. |
| 8/2 | 2026/09/12 13:55 | tool | grepper |
0mArgs:{
"Expression": "MTK_NET_PHYLIB",
"PathPrefix": "drivers/net/phy"
}Results: {
"Output": "drivers/net/phy/mediatek/Kconfig=2=config MEDIATEK_2P5GE_PHY\n--\ndrivers/net/phy/mediatek/Kconfig-4-\tdepends on (ARM64 \u0026\u0026 ARCH_MEDIATEK) || COMPILE_TEST\ndrivers/net/phy/mediatek/Kconfig:5:\tselect MTK_NET_PHYLIB\ndrivers/net/phy/mediatek/Kconfig-6-\thelp\n--\ndrivers/net/phy/mediatek/Kconfig=13=config MEDIATEK_GE_PHY\ndrivers/net/phy/mediatek/Kconfig-14-\ttristate \"MediaTek Gigabit Ethernet PHYs\"\ndrivers/net/phy/mediatek/Kconfig:15:\tselect MTK_NET_PHYLIB\ndrivers/net/phy/mediatek/Kconfig-16-\thelp\n--\ndrivers/net/phy/mediatek/Kconfig=33=config MEDIATEK_GE_SOC_PHY\n--\ndrivers/net/phy/mediatek/Kconfig-37-\t\t ECONET || COMPILE_TEST\ndrivers/net/phy/mediatek/Kconfig:38:\tselect MTK_NET_PHYLIB\ndrivers/net/phy/mediatek/Kconfig-39-\tselect PHY_PACKAGE\n--\ndrivers/net/phy/mediatek/Kconfig-51-\ndrivers/net/phy/mediatek/Kconfig:52:config MTK_NET_PHYLIB\ndrivers/net/phy/mediatek/Kconfig-53-\ttristate\n--\ndrivers/net/phy/mediatek/Makefile=5=obj-$(CONFIG_MEDIATEK_GE_SOC_PHY)\t+= mtk-ge-soc.o\ndrivers/net/phy/mediatek/Makefile:6:obj-$(CONFIG_MTK_NET_PHYLIB)\t\t+= mtk-phy-lib.o\n"
} |
| 9/2 | 2026/09/12 13:55 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 4815 output: 37 thoughts: 75 Thoughts: Okay, let's dive into these MTK Ethernet driver files: `mtk-2p5ge.c`, `mtk-ge.c`, and `mtk-ge-soc.c`. I need to understand how they function, and specifically, where and how `mtk_phy_led_hw_ctrl_get` is used within that context. I'll start with a straightforward approach: a quick `grep` for that function name across those files. That should give me a solid starting point to trace the call paths and understand its role in the bigger picture of the LED control mechanism. |
| 10/2 | 2026/09/12 13:55 | tool | grepper |
0mArgs:{
"Expression": "mtk_phy_led_hw_ctrl_get",
"PathPrefix": "drivers/net/phy"
}Results: {
"Output": "drivers/net/phy/mediatek/mtk-2p5ge.c=305=static int mt798x_2p5ge_phy_led_hw_control_get(struct phy_device *phydev,\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c-307-{\ndrivers/net/phy/mediatek/mtk-2p5ge.c:308:\treturn mtk_phy_led_hw_ctrl_get(phydev, index, rules,\ndrivers/net/phy/mediatek/mtk-2p5ge.c-309-\t\t\t\t MTK_2P5GPHY_LED_ON_SET,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c=1276=static int mt798x_phy_led_hw_control_get(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1278-{\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1279:\treturn mtk_phy_led_hw_ctrl_get(phydev, index, rules,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1280-\t\t\t\t MTK_GPHY_LED_ON_SET,\n--\ndrivers/net/phy/mediatek/mtk-phy-lib.c=111=EXPORT_SYMBOL_GPL(mtk_phy_led_hw_is_supported);\ndrivers/net/phy/mediatek/mtk-phy-lib.c-112-\ndrivers/net/phy/mediatek/mtk-phy-lib.c:113:int mtk_phy_led_hw_ctrl_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mediatek/mtk-phy-lib.c-114-\t\t\t unsigned long *rules, u16 on_set,\n--\ndrivers/net/phy/mediatek/mtk-phy-lib.c-194-}\ndrivers/net/phy/mediatek/mtk-phy-lib.c:195:EXPORT_SYMBOL_GPL(mtk_phy_led_hw_ctrl_get);\ndrivers/net/phy/mediatek/mtk-phy-lib.c-196-\n--\ndrivers/net/phy/mediatek/mtk.h=90=int mtk_phy_led_hw_ctrl_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/mediatek/mtk.h-92-\t\t\t u16 rx_blink_set, u16 tx_blink_set);\ndrivers/net/phy/mediatek/mtk.h:93:int mtk_phy_led_hw_ctrl_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mediatek/mtk.h-94-\t\t\t unsigned long *rules, u16 on_set,\n"
} |
| 11/2 | 2026/09/12 13:55 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 5808 output: 44 thoughts: 89 Thoughts: Okay, let's break this down. **Initial Assessment of Hardware Interaction Functions** Alright, so I'm presented with these two function names: `mt798x_2p5ge_phy_led_hw_control_get` and `mt798x_phy_led_hw_control_get`. The naming convention strongly suggests we're dealing with PHY (Physical Layer) LED hardware control. The "mt798x" prefix is a solid hint about the underlying Mediatek chipset. The presence of "2p5ge" in one name immediately indicates support for 2.5 Gigabit Ethernet. The absence of it in the other implies something more generic. My next step? Well, naturally, I'd want to examine the source code. Let's see... the suggested files are `drivers/net/phy/mediatek/mtk-2p5ge.c` and `mtk-ge-soc.c`. That looks promising. `mtk-2p5ge.c` would be the logical place to find the 2.5G specific implementation, and `mtk-ge-soc.c` likely deals with more general Gigabit Ethernet PHYs on Mediatek SoCs. I'll need to dig into these files to understand the control flow, the hardware registers being accessed, and the overall LED control strategy. I'm keen to see if they share any common code and if there's any abstraction in place. |
| 12/2 | 2026/09/12 13:55 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/mediatek/mtk-2p5ge.c",
"FirstLine": 1,
"LineCount": 50
}Results: {
"Contents": " 1:\t// SPDX-License-Identifier: GPL-2.0+\n 2:\t#include \u003clinux/bitfield.h\u003e\n 3:\t#include \u003clinux/firmware.h\u003e\n 4:\t#include \u003clinux/module.h\u003e\n 5:\t#include \u003clinux/of_address.h\u003e\n 6:\t#include \u003clinux/of_platform.h\u003e\n 7:\t#include \u003clinux/pinctrl/consumer.h\u003e\n 8:\t#include \u003clinux/phy.h\u003e\n 9:\t\n 10:\t#include \"mtk.h\"\n 11:\t\n 12:\t#define MTK_2P5GPHY_ID_MT7988\t\t0x00339c11\n 13:\t\n 14:\t#define MT7988_2P5GE_PMB_FW\t\t\"mediatek/mt7988/i2p5ge-phy-pmb.bin\"\n 15:\t#define MT7988_2P5GE_PMB_FW_SIZE\t0x20000\n 16:\t#define MT7988_2P5GE_PMB_FW_BASE\t0x0f100000\n 17:\t#define MT7988_2P5GE_PMB_FW_LEN\t\t0x20000\n 18:\t#define MTK_2P5GPHY_MCU_CSR_BASE\t0x0f0f0000\n 19:\t#define MTK_2P5GPHY_MCU_CSR_LEN\t\t0x20\n 20:\t#define MD32_EN_CFG\t\t\t0x18\n 21:\t#define MD32_EN\t\t\tBIT(0)\n 22:\t\n 23:\t#define BASE100T_STATUS_EXTEND\t\t0x10\n 24:\t#define BASE1000T_STATUS_EXTEND\t\t0x11\n 25:\t#define EXTEND_CTRL_AND_STATUS\t\t0x16\n 26:\t\n 27:\t#define PHY_AUX_CTRL_STATUS\t\t0x1d\n 28:\t#define PHY_AUX_DPX_MASK\t\tGENMASK(5, 5)\n 29:\t#define PHY_AUX_SPEED_MASK\t\tGENMASK(4, 2)\n 30:\t\n 31:\t/* Registers on MDIO_MMD_VEND1 */\n 32:\t#define MTK_PHY_LPI_PCS_DSP_CTRL\t\t0x121\n 33:\t#define MTK_PHY_LPI_SIG_EN_LO_THRESH100_MASK\tGENMASK(12, 8)\n 34:\t\n 35:\t#define MTK_PHY_HOST_CMD1\t\t0x800e\n 36:\t#define MTK_PHY_HOST_CMD2\t\t0x800f\n 37:\t/* Registers on Token Ring debug nodes */\n 38:\t/* ch_addr = 0x0, node_addr = 0xf, data_addr = 0x3c */\n 39:\t#define AUTO_NP_10XEN\t\t\t\tBIT(6)\n 40:\t\n 41:\tenum {\n 42:\t\tPHY_AUX_SPD_10 = 0,\n 43:\t\tPHY_AUX_SPD_100,\n 44:\t\tPHY_AUX_SPD_1000,\n 45:\t\tPHY_AUX_SPD_2500,\n 46:\t};\n 47:\t\n 48:\tstatic int mt798x_2p5ge_phy_load_fw(struct phy_device *phydev)\n 49:\t{\n 50:\t\tstruct device *dev = \u0026phydev-\u003emdio.dev;\n"
} |
| 13/2 | 2026/09/12 13:55 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 7230 output: 46 thoughts: 29 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience: **Diving into the MTK Ethernet Driver Landscape** Okay, time to get my hands dirty. I need to understand the relationship and potential differences between these two MediaTek Ethernet driver files: `mtk-2p5ge.c` and `mtk-ge-soc.c`. My immediate thought is, "Where's the specific implementation of the hardware and device-tree config that I'm interested in?" Given their filenames, I suspect `mtk-2p5ge.c` is the one containing the 2.5GBASE-T support, a more recent addition, or a more specialized variant. I'll need to confirm that. Therefore, the first thing I'll do is check the end of each file. I want to look for crucial items like: * **Platform-specific initialization:** are the same or different? * **Interrupt handlers:** How are interrupts handled? * **Driver registration and unregistration**: What's the module structure and how is it integrated into the kernel? * **Device-tree bindings:** This will show the actual hardware and how the two drivers interact. I'm anticipating that `mtk-ge-soc.c` likely provides a broader, more generic framework, perhaps handling basic Gigabit Ethernet PHYs and MDIO access, while `mtk-2p5ge.c` layers on top with the higher-speed-specific registers, signaling techniques, and possibly a different PHY configuration. I'll be looking for any indications of code sharing or inheritance between them. Understanding this relationship is key to debugging my networking issue. |
| 14/2 | 2026/09/12 13:55 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/mediatek/mtk-2p5ge.c",
"FirstLine": 310,
"LineCount": 80
}Results: {
"Contents": " 310:\t\t\t\t\t MTK_2P5GPHY_LED_RX_BLINK_SET,\n 311:\t\t\t\t\t MTK_2P5GPHY_LED_TX_BLINK_SET);\n 312:\t};\n 313:\t\n 314:\tstatic int mt798x_2p5ge_phy_led_hw_control_set(struct phy_device *phydev,\n 315:\t\t\t\t\t\t u8 index, unsigned long rules)\n 316:\t{\n 317:\t\treturn mtk_phy_led_hw_ctrl_set(phydev, index, rules,\n 318:\t\t\t\t\t MTK_2P5GPHY_LED_ON_SET,\n 319:\t\t\t\t\t MTK_2P5GPHY_LED_RX_BLINK_SET,\n 320:\t\t\t\t\t MTK_2P5GPHY_LED_TX_BLINK_SET);\n 321:\t};\n 322:\t\n 323:\tstatic int mt798x_2p5ge_phy_probe(struct phy_device *phydev)\n 324:\t{\n 325:\t\tstruct mtk_socphy_priv *priv;\n 326:\t\tstruct pinctrl *pinctrl;\n 327:\t\tint ret;\n 328:\t\n 329:\t\tswitch (phydev-\u003edrv-\u003ephy_id) {\n 330:\t\tcase MTK_2P5GPHY_ID_MT7988:\n 331:\t\t\t/* This built-in 2.5GbE hardware only sets MDIO_DEVS_PMAPMD.\n 332:\t\t\t * Set the rest by this driver since PCS/AN/VEND1/VEND2 MDIO\n 333:\t\t\t * manageable devices actually exist.\n 334:\t\t\t */\n 335:\t\t\tphydev-\u003ec45_ids.mmds_present |= MDIO_DEVS_PCS |\n 336:\t\t\t\t\t\t\tMDIO_DEVS_AN |\n 337:\t\t\t\t\t\t\tMDIO_DEVS_VEND1 |\n 338:\t\t\t\t\t\t\tMDIO_DEVS_VEND2;\n 339:\t\t\tbreak;\n 340:\t\tdefault:\n 341:\t\t\treturn -EINVAL;\n 342:\t\t}\n 343:\t\n 344:\t\tret = mt798x_2p5ge_phy_load_fw(phydev);\n 345:\t\tif (ret \u003c 0)\n 346:\t\t\treturn ret;\n 347:\t\n 348:\t\t/* Setup LED. On default, LED0 is on/off when link is up/down. As for\n 349:\t\t * LED1, it blinks as tx/rx transmission takes place.\n 350:\t\t */\n 351:\t\tphy_set_bits_mmd(phydev, MDIO_MMD_VEND2, MTK_PHY_LED0_ON_CTRL,\n 352:\t\t\t\t MTK_PHY_LED_ON_POLARITY | MTK_2P5GPHY_LED_ON_SET);\n 353:\t\tphy_clear_bits_mmd(phydev, MDIO_MMD_VEND2, MTK_PHY_LED0_BLINK_CTRL,\n 354:\t\t\t\t MTK_2P5GPHY_LED_TX_BLINK_SET |\n 355:\t\t\t\t MTK_2P5GPHY_LED_RX_BLINK_SET);\n 356:\t\tphy_clear_bits_mmd(phydev, MDIO_MMD_VEND2, MTK_PHY_LED1_ON_CTRL,\n 357:\t\t\t\t MTK_PHY_LED_ON_FDX | MTK_PHY_LED_ON_HDX |\n 358:\t\t\t\t MTK_2P5GPHY_LED_ON_SET);\n 359:\t\tphy_set_bits_mmd(phydev, MDIO_MMD_VEND2, MTK_PHY_LED1_BLINK_CTRL,\n 360:\t\t\t\t MTK_2P5GPHY_LED_TX_BLINK_SET |\n 361:\t\t\t\t MTK_2P5GPHY_LED_RX_BLINK_SET);\n 362:\t\n 363:\t\t/* Switch pinctrl after setting polarity to avoid bogus blinking */\n 364:\t\tpinctrl = devm_pinctrl_get_select(\u0026phydev-\u003emdio.dev, \"i2p5gbe-led\");\n 365:\t\tif (IS_ERR(pinctrl))\n 366:\t\t\tdev_err(\u0026phydev-\u003emdio.dev, \"Fail to set LED pins!\\n\");\n 367:\t\n 368:\t\tpriv = devm_kzalloc(\u0026phydev-\u003emdio.dev, sizeof(struct mtk_socphy_priv),\n 369:\t\t\t\t GFP_KERNEL);\n 370:\t\tif (!priv)\n 371:\t\t\treturn -ENOMEM;\n 372:\t\tphydev-\u003epriv = priv;\n 373:\t\n 374:\t\tmtk_phy_leds_state_init(phydev);\n 375:\t\n 376:\t\treturn 0;\n 377:\t}\n 378:\t\n 379:\tstatic struct phy_driver mtk_2p5gephy_driver[] = {\n 380:\t\t{\n 381:\t\t\tPHY_ID_MATCH_MODEL(MTK_2P5GPHY_ID_MT7988),\n 382:\t\t\t.name = \"MediaTek MT7988 2.5GbE PHY\",\n 383:\t\t\t.probe = mt798x_2p5ge_phy_probe,\n 384:\t\t\t.config_init = mt798x_2p5ge_phy_config_init,\n 385:\t\t\t.config_aneg = mt798x_2p5ge_phy_config_aneg,\n 386:\t\t\t.get_features = mt798x_2p5ge_phy_get_features,\n 387:\t\t\t.read_status = mt798x_2p5ge_phy_read_status,\n 388:\t\t\t.get_rate_matching = mt798x_2p5ge_phy_get_rate_matching,\n 389:\t\t\t.suspend = genphy_suspend,\n"
} |
| 15/2 | 2026/09/12 13:55 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 9276 output: 46 thoughts: 70 Thoughts: Here's my summary, as though I'm thinking through this process: **Diving into the MTK 2.5G Ethernet Driver: LED Control** Okay, so I'm looking at the `mtk_2p5gephy_driver` module. I need to understand its LED control mechanism, and it looks like it provides the usual suspects. I see functions like `led_hw_is_supported`, `led_hw_control_get`, and `led_hw_control_set` in the code, which is exactly what I'd expect. These suggest that the driver handles the hardware interaction for the LEDs directly. Now, let's get specific. I'm going to jump to `mtk-2p5ge.c` and specifically lines 390 to 410. That should give me a good view of how these LED functions are implemented, and I can probably glean the register mappings or hardware interaction directly from the code to work out what the state machine is for the LED controls, and how the driver interfaces with it. From there, I should be able to work out how to make changes if necessary. |
| 16/2 | 2026/09/12 13:55 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/mediatek/mtk-2p5ge.c",
"FirstLine": 390,
"LineCount": 30
}Results: {
"Contents": " 390:\t\t\t.resume = genphy_resume,\n 391:\t\t\t.read_page = mtk_phy_read_page,\n 392:\t\t\t.write_page = mtk_phy_write_page,\n 393:\t\t\t.led_blink_set = mt798x_2p5ge_phy_led_blink_set,\n 394:\t\t\t.led_brightness_set = mt798x_2p5ge_phy_led_brightness_set,\n 395:\t\t\t.led_hw_is_supported = mt798x_2p5ge_phy_led_hw_is_supported,\n 396:\t\t\t.led_hw_control_get = mt798x_2p5ge_phy_led_hw_control_get,\n 397:\t\t\t.led_hw_control_set = mt798x_2p5ge_phy_led_hw_control_set,\n 398:\t\t},\n 399:\t};\n 400:\t\n 401:\tmodule_phy_driver(mtk_2p5gephy_driver);\n 402:\t\n 403:\tstatic struct mdio_device_id __maybe_unused mtk_2p5ge_phy_tbl[] = {\n 404:\t\t{ PHY_ID_MATCH_VENDOR(0x00339c00) },\n 405:\t\t{ }\n 406:\t};\n 407:\t\n 408:\tMODULE_DESCRIPTION(\"MediaTek 2.5Gb Ethernet PHY driver\");\n 409:\tMODULE_AUTHOR(\"SkyLake Huang \u003cSkyLake.Huang@mediatek.com\u003e\");\n 410:\tMODULE_LICENSE(\"GPL\");\n 411:\t\n 412:\tMODULE_DEVICE_TABLE(mdio, mtk_2p5ge_phy_tbl);\n 413:\tMODULE_FIRMWARE(MT7988_2P5GE_PMB_FW);\n"
} |
| 17/2 | 2026/09/12 13:55 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 10150 output: 43 thoughts: 38 Thoughts: Okay, let's dive into this. Here's my thought process on checking `mtk-ge-soc.c`: **Hunting Down the LED Control Function** Alright, I need to see where `mt798x_phy_led_hw_control_get` is actually being utilized within this specific code base. Since I'm working with a MediaTek Gigabit Ethernet SoC, this function likely plays a crucial role in managing the hardware-level control of the PHY's LEDs. Understanding its context will be key to figuring out how LED behavior is implemented, configured, or potentially debugged. Time to fire up the editor and take a look at the code. This will tell me how LEDs are mapped to specific states, or even more complex configurations based on port activity or link status. It's time to find its implementation details and any associated comments for a deeper understanding. |
| 18/2 | 2026/09/12 13:55 | tool | grepper |
0mArgs:{
"Expression": "mt798x_phy_led_hw_control_get",
"PathPrefix": "drivers/net/phy/mediatek"
}Results: {
"Output": "drivers/net/phy/mediatek/mtk-ge-soc.c=1269=static int mt798x_phy_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1275-\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1276:static int mt798x_phy_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1277-\t\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c=1495=static struct phy_driver mtk_socphy_driver[] = {\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1510-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1511:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1512-\t},\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1527-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1528:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1529-\t},\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1538-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1539:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1540-\t\t.led_polarity_set = an7581_phy_led_polarity_set,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1551-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1552:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1553-\t\t.led_polarity_set = an7581_phy_led_polarity_set,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1563-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1564:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1565-\t\t.led_polarity_set = an7581_phy_led_polarity_set,\n"
} |
| 19/2 | 2026/09/12 13:55 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 11333 output: 42 thoughts: 132 Thoughts: **My Current Inquiry: Instantiating and Fuzzing PHY Devices in a QEMU/Syzkaller Environment** Okay, so I'm trying to figure out if I can actually get PHY devices or, more specifically, MDIO PHY drivers, up and running for fuzzing within a standard QEMU/syzkaller setup. It's a tricky problem. First, I need to understand how these PHY devices even *exist* in the Linux kernel. How are they created? How are they probed? What's the fundamental mechanism? I need to quickly establish the core pathway: Are there virtual MDIO buses that are usable, or is everything fundamentally tied to some real-world hardware, which will significantly complicate this process? But wait. Before I go too far down that rabbit hole, a more fundamental question: can I create and simulate an MDIO PHY device from userspace, somehow? That would be ideal for controllability. I need to explore the relevant kernel functions: `mdiobus_register`, `mdio_device`, maybe even `netdevphy`... What's the standard way of registering or simulating an MDIO connection? Finally, let's go straight to the source, since a lot of this is in the `drivers/net/mdio` directory. I'm going to run a quick `grep` for "MDIO" in that specific directory. That'll probably be the fastest way to get a grasp on the key modules that I need to investigate. This will hopefully help me understand what data I need to input to QEMU/Syzkaller to reproduce the setup that I am looking for. |
| 20/2 | 2026/09/12 13:55 | tool | grepper |
0mArgs:{
"Expression": "mdio.*user|mdio_gpio|mdio-gpio|virtual.*mdio",
"PathPrefix": "drivers/net"
}Results: {
"Output": "drivers/net/dsa/b53/b53_common.c=1128=static struct phy_device *b53_get_phy_device(struct dsa_switch *ds, int port)\n--\ndrivers/net/dsa/b53/b53_common.c-1137-\ndrivers/net/dsa/b53/b53_common.c:1138:\treturn mdiobus_get_phy(ds-\u003euser_mii_bus, port);\ndrivers/net/dsa/b53/b53_common.c-1139-}\n--\ndrivers/net/dsa/b53/b53_mdio.c=292=static int b53_mdio_probe(struct mdio_device *mdiodev)\n--\ndrivers/net/dsa/b53/b53_mdio.c-331-\tif (of_machine_is_compatible(\"brcm,bcm7445d0\") \u0026\u0026\ndrivers/net/dsa/b53/b53_mdio.c:332:\t strcmp(mdiodev-\u003ebus-\u003ename, \"sf2 user mii\"))\ndrivers/net/dsa/b53/b53_mdio.c-333-\t\treturn -EPROBE_DEFER;\n--\ndrivers/net/dsa/bcm_sf2.c=607=static int bcm_sf2_mdio_register(struct dsa_switch *ds)\n--\ndrivers/net/dsa/bcm_sf2.c-683-\ndrivers/net/dsa/bcm_sf2.c:684:\terr = mdiobus_register(priv-\u003euser_mii_bus);\ndrivers/net/dsa/bcm_sf2.c-685-\tif (err)\n--\ndrivers/net/dsa/bcm_sf2.c-692-err_free_user_mii_bus:\ndrivers/net/dsa/bcm_sf2.c:693:\tmdiobus_free(priv-\u003euser_mii_bus);\ndrivers/net/dsa/bcm_sf2.c-694-err_put_master_mii_bus_dev:\n--\ndrivers/net/dsa/bcm_sf2.c=701=static void bcm_sf2_mdio_unregister(struct bcm_sf2_priv *priv)\ndrivers/net/dsa/bcm_sf2.c-702-{\ndrivers/net/dsa/bcm_sf2.c:703:\tmdiobus_unregister(priv-\u003euser_mii_bus);\ndrivers/net/dsa/bcm_sf2.c:704:\tmdiobus_free(priv-\u003euser_mii_bus);\ndrivers/net/dsa/bcm_sf2.c-705-\tput_device(\u0026priv-\u003emaster_mii_bus-\u003edev);\n--\ndrivers/net/dsa/realtek/rtl83xx.c=56=static int rtl83xx_user_mdio_write(struct mii_bus *bus, int addr, int regnum,\n--\ndrivers/net/dsa/realtek/rtl83xx.c-64-/**\ndrivers/net/dsa/realtek/rtl83xx.c:65: * rtl83xx_setup_user_mdio() - register the user mii bus driver\ndrivers/net/dsa/realtek/rtl83xx.c-66- * @ds: DSA switch associated with this user_mii_bus\n--\ndrivers/net/mdio/Kconfig=90=config MDIO_GPIO\n--\ndrivers/net/mdio/Kconfig-97-\t To compile this driver as a module, choose M here: the module\ndrivers/net/mdio/Kconfig:98:\t will be called mdio-gpio.\ndrivers/net/mdio/Kconfig-99-\n--\ndrivers/net/mdio/Makefile=13=obj-$(CONFIG_MDIO_CAVIUM)\t\t+= mdio-cavium.o\ndrivers/net/mdio/Makefile:14:obj-$(CONFIG_MDIO_GPIO)\t\t\t+= mdio-gpio.o\ndrivers/net/mdio/Makefile-15-obj-$(CONFIG_MDIO_HISI_FEMAC)\t\t+= mdio-hisi-femac.o\n--\ndrivers/net/mdio/mdio-gpio.c-31-\ndrivers/net/mdio/mdio-gpio.c:32:struct mdio_gpio_info {\ndrivers/net/mdio/mdio-gpio.c-33-\tstruct mdiobb_ctrl ctrl;\n--\ndrivers/net/mdio/mdio-gpio.c-36-\ndrivers/net/mdio/mdio-gpio.c:37:static int mdio_gpio_get_data(struct device *dev,\ndrivers/net/mdio/mdio-gpio.c:38:\t\t\t struct mdio_gpio_info *bitbang)\ndrivers/net/mdio/mdio-gpio.c-39-{\n--\ndrivers/net/mdio/mdio-gpio.c=55=static void mdio_dir(struct mdiobb_ctrl *ctrl, int dir)\ndrivers/net/mdio/mdio-gpio.c-56-{\ndrivers/net/mdio/mdio-gpio.c:57:\tstruct mdio_gpio_info *bitbang =\ndrivers/net/mdio/mdio-gpio.c:58:\t\tcontainer_of(ctrl, struct mdio_gpio_info, ctrl);\ndrivers/net/mdio/mdio-gpio.c-59-\n--\ndrivers/net/mdio/mdio-gpio.c=76=static int mdio_get(struct mdiobb_ctrl *ctrl)\ndrivers/net/mdio/mdio-gpio.c-77-{\ndrivers/net/mdio/mdio-gpio.c:78:\tstruct mdio_gpio_info *bitbang =\ndrivers/net/mdio/mdio-gpio.c:79:\t\tcontainer_of(ctrl, struct mdio_gpio_info, ctrl);\ndrivers/net/mdio/mdio-gpio.c-80-\n--\ndrivers/net/mdio/mdio-gpio.c=84=static void mdio_set(struct mdiobb_ctrl *ctrl, int what)\ndrivers/net/mdio/mdio-gpio.c-85-{\ndrivers/net/mdio/mdio-gpio.c:86:\tstruct mdio_gpio_info *bitbang =\ndrivers/net/mdio/mdio-gpio.c:87:\t\tcontainer_of(ctrl, struct mdio_gpio_info, ctrl);\ndrivers/net/mdio/mdio-gpio.c-88-\n--\ndrivers/net/mdio/mdio-gpio.c=95=static void mdc_set(struct mdiobb_ctrl *ctrl, int what)\ndrivers/net/mdio/mdio-gpio.c-96-{\ndrivers/net/mdio/mdio-gpio.c:97:\tstruct mdio_gpio_info *bitbang =\ndrivers/net/mdio/mdio-gpio.c:98:\t\tcontainer_of(ctrl, struct mdio_gpio_info, ctrl);\ndrivers/net/mdio/mdio-gpio.c-99-\n--\ndrivers/net/mdio/mdio-gpio.c-102-\ndrivers/net/mdio/mdio-gpio.c:103:static const struct mdiobb_ops mdio_gpio_ops = {\ndrivers/net/mdio/mdio-gpio.c-104-\t.owner = THIS_MODULE,\n--\ndrivers/net/mdio/mdio-gpio.c-110-\ndrivers/net/mdio/mdio-gpio.c:111:static struct mii_bus *mdio_gpio_bus_init(struct device *dev,\ndrivers/net/mdio/mdio-gpio.c:112:\t\t\t\t\t struct mdio_gpio_info *bitbang,\ndrivers/net/mdio/mdio-gpio.c-113-\t\t\t\t\t int bus_id)\n--\ndrivers/net/mdio/mdio-gpio.c-116-\ndrivers/net/mdio/mdio-gpio.c:117:\tbitbang-\u003ectrl.ops = \u0026mdio_gpio_ops;\ndrivers/net/mdio/mdio-gpio.c-118-\n--\ndrivers/net/mdio/mdio-gpio.c-141-\ndrivers/net/mdio/mdio-gpio.c:142:static void mdio_gpio_bus_deinit(struct device *dev)\ndrivers/net/mdio/mdio-gpio.c-143-{\n--\ndrivers/net/mdio/mdio-gpio.c-148-\ndrivers/net/mdio/mdio-gpio.c:149:static void mdio_gpio_bus_destroy(struct device *dev)\ndrivers/net/mdio/mdio-gpio.c-150-{\n--\ndrivers/net/mdio/mdio-gpio.c-153-\tmdiobus_unregister(bus);\ndrivers/net/mdio/mdio-gpio.c:154:\tmdio_gpio_bus_deinit(dev);\ndrivers/net/mdio/mdio-gpio.c-155-}\ndrivers/net/mdio/mdio-gpio.c-156-\ndrivers/net/mdio/mdio-gpio.c:157:static int mdio_gpio_probe(struct platform_device *pdev)\ndrivers/net/mdio/mdio-gpio.c-158-{\ndrivers/net/mdio/mdio-gpio.c:159:\tstruct mdio_gpio_info *bitbang;\ndrivers/net/mdio/mdio-gpio.c-160-\tstruct mii_bus *new_bus;\n--\ndrivers/net/mdio/mdio-gpio.c-166-\ndrivers/net/mdio/mdio-gpio.c:167:\tret = mdio_gpio_get_data(\u0026pdev-\u003edev, bitbang);\ndrivers/net/mdio/mdio-gpio.c-168-\tif (ret)\n--\ndrivers/net/mdio/mdio-gpio.c-171-\tif (pdev-\u003edev.of_node) {\ndrivers/net/mdio/mdio-gpio.c:172:\t\tbus_id = of_alias_get_id(pdev-\u003edev.of_node, \"mdio-gpio\");\ndrivers/net/mdio/mdio-gpio.c-173-\t\tif (bus_id \u003c 0) {\n--\ndrivers/net/mdio/mdio-gpio.c-180-\ndrivers/net/mdio/mdio-gpio.c:181:\tnew_bus = mdio_gpio_bus_init(\u0026pdev-\u003edev, bitbang, bus_id);\ndrivers/net/mdio/mdio-gpio.c-182-\tif (!new_bus)\n--\ndrivers/net/mdio/mdio-gpio.c-186-\tif (ret)\ndrivers/net/mdio/mdio-gpio.c:187:\t\tmdio_gpio_bus_deinit(\u0026pdev-\u003edev);\ndrivers/net/mdio/mdio-gpio.c-188-\n--\ndrivers/net/mdio/mdio-gpio.c-191-\ndrivers/net/mdio/mdio-gpio.c:192:static void mdio_gpio_remove(struct platform_device *pdev)\ndrivers/net/mdio/mdio-gpio.c-193-{\ndrivers/net/mdio/mdio-gpio.c:194:\tmdio_gpio_bus_destroy(\u0026pdev-\u003edev);\ndrivers/net/mdio/mdio-gpio.c-195-}\ndrivers/net/mdio/mdio-gpio.c-196-\ndrivers/net/mdio/mdio-gpio.c:197:static const struct of_device_id mdio_gpio_of_match[] = {\ndrivers/net/mdio/mdio-gpio.c:198:\t{ .compatible = \"virtual,mdio-gpio\", },\ndrivers/net/mdio/mdio-gpio.c-199-\t{ .compatible = \"microchip,mdio-smi0\" },\n--\ndrivers/net/mdio/mdio-gpio.c-201-};\ndrivers/net/mdio/mdio-gpio.c:202:MODULE_DEVICE_TABLE(of, mdio_gpio_of_match);\ndrivers/net/mdio/mdio-gpio.c-203-\ndrivers/net/mdio/mdio-gpio.c:204:static struct platform_driver mdio_gpio_driver = {\ndrivers/net/mdio/mdio-gpio.c:205:\t.probe = mdio_gpio_probe,\ndrivers/net/mdio/mdio-gpio.c:206:\t.remove = mdio_gpio_remove,\ndrivers/net/mdio/mdio-gpio.c-207-\t.driver\t\t= {\ndrivers/net/mdio/mdio-gpio.c:208:\t\t.name\t= \"mdio-gpio\",\ndrivers/net/mdio/mdio-gpio.c:209:\t\t.of_match_table = mdio_gpio_of_match,\ndrivers/net/mdio/mdio-gpio.c-210-\t},\n--\ndrivers/net/mdio/mdio-gpio.c-212-\ndrivers/net/mdio/mdio-gpio.c:213:module_platform_driver(mdio_gpio_driver);\ndrivers/net/mdio/mdio-gpio.c-214-\ndrivers/net/mdio/mdio-gpio.c:215:MODULE_ALIAS(\"platform:mdio-gpio\");\ndrivers/net/mdio/mdio-gpio.c-216-MODULE_AUTHOR(\"Laurent Pinchart, Paulius Zaleckas\");\n--\ndrivers/net/mdio/mdio-ipq8064.c=98=static const struct regmap_config ipq8064_mdio_regmap_config = {\n--\ndrivers/net/mdio/mdio-ipq8064.c-102-\t.can_multi_write = false,\ndrivers/net/mdio/mdio-ipq8064.c:103:\t/* the mdio lock is used by any user of this mdio driver */\ndrivers/net/mdio/mdio-ipq8064.c-104-\t.disable_locking = true,\n"
} |
| 21/2 | 2026/09/12 13:55 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 15510 output: 30 thoughts: 203 Thoughts: **My Current Train of Thought** Okay, hold on a second. I need to clarify how these PHY devices are actually probed. When an MDIO bus is being scanned, or during PHY registration – when we're creating or registering a PHY device, like with `phy_device_create`, `phy_device_register`, or `get_phy_device` – the system iterates through the addresses, from 0 to 31. Then, it reads the `MII_PHYSID1` and `MII_PHYSID2` registers. If that data matches the `phy_id` and `phy_id_mask` of a specific PHY driver, that's when the driver knows it's the right one and probes the device. Now, a critical question for me: Can syzkaller somehow create or emulate an MDIO bus specifically with MediaTek PHYs? That would be incredibly useful for fuzzing. Also, I'm now wondering if USB ethernet dongles can even *have* PHYs. Yes, of course, some of them do – like the asix, ax88179_178a devices, and others. Those have MDIO buses! Now, to refine the thought process. Let's see if there are any USB ethernet dongles which use standard `phy_device` components. I think I'll just grep for `mdiobus_register` within the `drivers/net/usb` directory to check. That should give me a good overview of how those devices are set up and how they interact with the MDIO bus. |
| 22/2 | 2026/09/12 13:55 | tool | grepper |
0mArgs:{
"Expression": "mdiobus_register",
"PathPrefix": "drivers/net/usb"
}Results: {
"Output": "drivers/net/usb/asix_devices.c=669=static int ax88772_init_mdio(struct usbnet *dev)\n--\ndrivers/net/usb/asix_devices.c-686-\ndrivers/net/usb/asix_devices.c:687:\tret = mdiobus_register(priv-\u003emdio);\ndrivers/net/usb/asix_devices.c-688-\tif (ret) {\n--\ndrivers/net/usb/ax88172a.c=61=static int ax88172a_init_mdio(struct usbnet *dev)\n--\ndrivers/net/usb/ax88172a.c-79-\ndrivers/net/usb/ax88172a.c:80:\tret = mdiobus_register(priv-\u003emdio);\ndrivers/net/usb/ax88172a.c-81-\tif (ret) {\n--\ndrivers/net/usb/lan78xx.c=2091=static int lan78xx_mdio_init(struct lan78xx_net *dev)\n--\ndrivers/net/usb/lan78xx.c-2121-\tnode = of_get_child_by_name(dev-\u003eudev-\u003edev.of_node, \"mdio\");\ndrivers/net/usb/lan78xx.c:2122:\tret = of_mdiobus_register(dev-\u003emdiobus, node);\ndrivers/net/usb/lan78xx.c-2123-\tof_node_put(node);\n--\ndrivers/net/usb/smsc95xx.c=1147=static int smsc95xx_bind(struct usbnet *dev, struct usb_interface *intf)\n--\ndrivers/net/usb/smsc95xx.c-1241-\ndrivers/net/usb/smsc95xx.c:1242:\tret = mdiobus_register(pdata-\u003emdiobus);\ndrivers/net/usb/smsc95xx.c-1243-\tif (ret) {\n"
} |
| 23/2 | 2026/09/12 13:55 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 16617 output: 37 thoughts: 616 Thoughts: **MDIO Bus Discovery and PHY Driver Matching: A USB-Emulated Twist** Okay, so I'm looking at this code and immediately see a pattern: `ax88772_init_mdio`, `ax88172a_init_mdio`, `smsc95xx_bind` – they all call `mdiobus_register`. Right, `mdiobus_register` is the key. It's the function that initiates the MDIO bus scan. Let's dig in to what it does. `mdiobus_register`'s got the goods, tucked away in `drivers/net/phy/mdio_bus.c`. I see `__mdiobus_register`, and it's scanning those PHY addresses. Reads PHY IDs off the bus. Okay, if it finds something, it creates a `phy_device` and registers it using `phy_device_register`, which in turn leads to a `device_register(&phydev->mdio.dev)`. Standard driver core stuff. The critical bit is the PHY ID matching. The driver core needs to match the `phy_driver` by the PHY ID, using `phy_bus_match`. Now, where this gets interesting, is the connection to USB emulation. I'm thinking about those USB ethernet devices, like `asix`, or others emulated through USB Raw Gadget and syzkaller. Syzkaller's USB emulation via `/dev/raw-gadget` is super powerful. When these emulated USB devices are "connected," the USB driver kicks in, sets up the MDIO bus, and we're good to go. The MDIO bus uses read/write callbacks to send USB control requests to the USB device. Here's the rub. What happens if the emulated USB device *responds* to the MII_PHYSID1 and MII_PHYSID2 register reads with a valid PHY ID? Say, like, `MTK_2P5GPHY_ID_MT7988` or even `MTK_GPHY_ID_*`? It would be quite interesting to look at the consequences in this case. Okay, I need to check which PHY drivers are using `mtk-phy-lib.c`. I'll have to see where `CONFIG_MTK_NET_PHYLIB` is being used and then look for where `mtk_phy_led_hw_ctrl_get` is called. Oh, here we go, earlier I grepped for `mtk_phy_led_hw_ctrl_get`. Looks like only two files are using it: 1) `drivers/net/phy/mediatek/mtk-2p5ge.c`: `mt798x_2p5ge_phy_led_hw_control_get`, specifically used in `mtk_2p5gephy_driver` for `MTK_2P5GPHY_ID_MT7988`. This looks promising to test against the emulation. 2) `drivers/net/phy/mediatek/mtk-ge-soc.c`: `mt798x_phy_led_hw_control_get` used in `mtk_socphy_driver`. I wonder if `mtk-ge.c` also uses `mtk_phy_led_hw_ctrl_get`. I should check that along with `mtk-phy-lib.c`. We need to see if we can trick the system into thinking these emulated devices are Mediatek PHYs. |
| 24/2 | 2026/09/12 13:55 | tool | grepper |
0mArgs:{
"Expression": "mtk_phy_led_hw_",
"PathPrefix": "drivers/net/phy/mediatek"
}Results: {
"Output": "drivers/net/phy/mediatek/mtk-2p5ge.c=298=static int mt798x_2p5ge_phy_led_hw_is_supported(struct phy_device *phydev,\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c-300-{\ndrivers/net/phy/mediatek/mtk-2p5ge.c:301:\treturn mtk_phy_led_hw_is_supported(phydev, index, rules,\ndrivers/net/phy/mediatek/mtk-2p5ge.c-302-\t\t\t\t\t supported_triggers);\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c=305=static int mt798x_2p5ge_phy_led_hw_control_get(struct phy_device *phydev,\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c-307-{\ndrivers/net/phy/mediatek/mtk-2p5ge.c:308:\treturn mtk_phy_led_hw_ctrl_get(phydev, index, rules,\ndrivers/net/phy/mediatek/mtk-2p5ge.c-309-\t\t\t\t MTK_2P5GPHY_LED_ON_SET,\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c=314=static int mt798x_2p5ge_phy_led_hw_control_set(struct phy_device *phydev,\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c-316-{\ndrivers/net/phy/mediatek/mtk-2p5ge.c:317:\treturn mtk_phy_led_hw_ctrl_set(phydev, index, rules,\ndrivers/net/phy/mediatek/mtk-2p5ge.c-318-\t\t\t\t MTK_2P5GPHY_LED_ON_SET,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c=1269=static int mt798x_phy_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1271-{\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1272:\treturn mtk_phy_led_hw_is_supported(phydev, index, rules,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1273-\t\t\t\t\t supported_triggers);\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c=1276=static int mt798x_phy_led_hw_control_get(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1278-{\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1279:\treturn mtk_phy_led_hw_ctrl_get(phydev, index, rules,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1280-\t\t\t\t MTK_GPHY_LED_ON_SET,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c=1285=static int mt798x_phy_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1287-{\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1288:\treturn mtk_phy_led_hw_ctrl_set(phydev, index, rules,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1289-\t\t\t\t MTK_GPHY_LED_ON_SET,\n--\ndrivers/net/phy/mediatek/mtk-phy-lib.c=96=EXPORT_SYMBOL_GPL(mtk_phy_write_page);\ndrivers/net/phy/mediatek/mtk-phy-lib.c-97-\ndrivers/net/phy/mediatek/mtk-phy-lib.c:98:int mtk_phy_led_hw_is_supported(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mediatek/mtk-phy-lib.c-99-\t\t\t\tunsigned long rules,\n--\ndrivers/net/phy/mediatek/mtk-phy-lib.c-110-}\ndrivers/net/phy/mediatek/mtk-phy-lib.c:111:EXPORT_SYMBOL_GPL(mtk_phy_led_hw_is_supported);\ndrivers/net/phy/mediatek/mtk-phy-lib.c-112-\ndrivers/net/phy/mediatek/mtk-phy-lib.c:113:int mtk_phy_led_hw_ctrl_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mediatek/mtk-phy-lib.c-114-\t\t\t unsigned long *rules, u16 on_set,\n--\ndrivers/net/phy/mediatek/mtk-phy-lib.c-161-\t * on_set holds every speed this LED can indicate and is what\ndrivers/net/phy/mediatek/mtk-phy-lib.c:162:\t * mtk_phy_led_hw_ctrl_set() programs for TRIGGER_NETDEV_LINK, so\ndrivers/net/phy/mediatek/mtk-phy-lib.c-163-\t * report the speed independent rule only when they are all on.\n--\ndrivers/net/phy/mediatek/mtk-phy-lib.c-194-}\ndrivers/net/phy/mediatek/mtk-phy-lib.c:195:EXPORT_SYMBOL_GPL(mtk_phy_led_hw_ctrl_get);\ndrivers/net/phy/mediatek/mtk-phy-lib.c-196-\ndrivers/net/phy/mediatek/mtk-phy-lib.c:197:int mtk_phy_led_hw_ctrl_set(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mediatek/mtk-phy-lib.c-198-\t\t\t unsigned long rules, u16 on_set,\n--\ndrivers/net/phy/mediatek/mtk-phy-lib.c-273-}\ndrivers/net/phy/mediatek/mtk-phy-lib.c:274:EXPORT_SYMBOL_GPL(mtk_phy_led_hw_ctrl_set);\ndrivers/net/phy/mediatek/mtk-phy-lib.c-275-\n--\ndrivers/net/phy/mediatek/mtk.h=85=int mtk_phy_write_page(struct phy_device *phydev, int page);\ndrivers/net/phy/mediatek/mtk.h-86-\ndrivers/net/phy/mediatek/mtk.h:87:int mtk_phy_led_hw_is_supported(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mediatek/mtk.h-88-\t\t\t\tunsigned long rules,\ndrivers/net/phy/mediatek/mtk.h-89-\t\t\t\tunsigned long supported_triggers);\ndrivers/net/phy/mediatek/mtk.h:90:int mtk_phy_led_hw_ctrl_set(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mediatek/mtk.h-91-\t\t\t unsigned long rules, u16 on_set,\ndrivers/net/phy/mediatek/mtk.h-92-\t\t\t u16 rx_blink_set, u16 tx_blink_set);\ndrivers/net/phy/mediatek/mtk.h:93:int mtk_phy_led_hw_ctrl_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mediatek/mtk.h-94-\t\t\t unsigned long *rules, u16 on_set,\n"
} |
| 25/2 | 2026/09/12 13:55 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 20085 output: 45 thoughts: 345 Thoughts: **Analyzing PHY Driver Compatibility** Okay, so I'm wondering if either `mtk_socphy_driver` or `mtk_2p5gephy_driver` can actually probe on amd64 when running within QEMU. Let's dig in and check the probe functions of each driver. First up, let's look at `mt798x_2p5ge_phy_probe`. Hmm, seems like it's trying to load firmware with `mt798x_2p5ge_phy_load_fw`. Interesting, what does that function even *do*? Gotta check that out. Now, to examine lines 48-110 in `mtk-2p5ge.c` and see if there are any clues. |
| 26/2 | 2026/09/12 13:55 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/mediatek/mtk-2p5ge.c",
"FirstLine": 48,
"LineCount": 60
}Results: {
"Contents": " 48:\tstatic int mt798x_2p5ge_phy_load_fw(struct phy_device *phydev)\n 49:\t{\n 50:\t\tstruct device *dev = \u0026phydev-\u003emdio.dev;\n 51:\t\tvoid __iomem *mcu_csr_base, *pmb_addr;\n 52:\t\tconst struct firmware *fw;\n 53:\t\tint ret, i;\n 54:\t\tu32 reg;\n 55:\t\n 56:\t\tpmb_addr = ioremap(MT7988_2P5GE_PMB_FW_BASE, MT7988_2P5GE_PMB_FW_LEN);\n 57:\t\tif (!pmb_addr)\n 58:\t\t\treturn -ENOMEM;\n 59:\t\tmcu_csr_base = ioremap(MTK_2P5GPHY_MCU_CSR_BASE,\n 60:\t\t\t\t MTK_2P5GPHY_MCU_CSR_LEN);\n 61:\t\tif (!mcu_csr_base) {\n 62:\t\t\tret = -ENOMEM;\n 63:\t\t\tgoto free_pmb;\n 64:\t\t}\n 65:\t\n 66:\t\tret = request_firmware_direct(\u0026fw, MT7988_2P5GE_PMB_FW, dev);\n 67:\t\tif (ret) {\n 68:\t\t\tdev_err(dev, \"failed to load firmware: %s, ret: %d\\n\",\n 69:\t\t\t\tMT7988_2P5GE_PMB_FW, ret);\n 70:\t\t\tgoto free;\n 71:\t\t}\n 72:\t\n 73:\t\tif (fw-\u003esize != MT7988_2P5GE_PMB_FW_SIZE) {\n 74:\t\t\tdev_err(dev, \"Firmware size 0x%zx != 0x%x\\n\",\n 75:\t\t\t\tfw-\u003esize, MT7988_2P5GE_PMB_FW_SIZE);\n 76:\t\t\tret = -EINVAL;\n 77:\t\t\tgoto release_fw;\n 78:\t\t}\n 79:\t\n 80:\t\treg = readw(mcu_csr_base + MD32_EN_CFG);\n 81:\t\tif (reg \u0026 MD32_EN) {\n 82:\t\t\tphy_set_bits(phydev, MII_BMCR, BMCR_RESET);\n 83:\t\t\tusleep_range(10000, 11000);\n 84:\t\t}\n 85:\t\tphy_set_bits(phydev, MII_BMCR, BMCR_PDOWN);\n 86:\t\n 87:\t\t/* Write magic number to safely stall MCU */\n 88:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND1, MTK_PHY_HOST_CMD1, 0x1100);\n 89:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND1, MTK_PHY_HOST_CMD2, 0x00df);\n 90:\t\n 91:\t\tfor (i = 0; i \u003c MT7988_2P5GE_PMB_FW_SIZE - 1; i += 4)\n 92:\t\t\twritel(*((uint32_t *)(fw-\u003edata + i)), pmb_addr + i);\n 93:\t\n 94:\t\twritew(reg \u0026 ~MD32_EN, mcu_csr_base + MD32_EN_CFG);\n 95:\t\twritew(reg | MD32_EN, mcu_csr_base + MD32_EN_CFG);\n 96:\t\tphy_set_bits(phydev, MII_BMCR, BMCR_RESET);\n 97:\t\t/* We need a delay here to stabilize initialization of MCU */\n 98:\t\tusleep_range(7000, 8000);\n 99:\t\n 100:\t\tdev_info(dev, \"Firmware date code: %x/%x/%x, version: %x.%x\\n\",\n 101:\t\t\t be16_to_cpu(*((__be16 *)(fw-\u003edata +\n 102:\t\t\t\t\t\t MT7988_2P5GE_PMB_FW_SIZE - 8))),\n 103:\t\t\t *(fw-\u003edata + MT7988_2P5GE_PMB_FW_SIZE - 6),\n 104:\t\t\t *(fw-\u003edata + MT7988_2P5GE_PMB_FW_SIZE - 5),\n 105:\t\t\t *(fw-\u003edata + MT7988_2P5GE_PMB_FW_SIZE - 2),\n 106:\t\t\t *(fw-\u003edata + MT7988_2P5GE_PMB_FW_SIZE - 1));\n 107:\t\n"
} |
| 27/2 | 2026/09/12 13:55 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 21896 output: 41 thoughts: 114 Thoughts: **Analyzing the MT798x 2.5G PHY Firmware Loading** Okay, so I'm looking at this `mt798x_2p5ge_phy_load_fw` function. My first thought is, this is where the PHY firmware gets loaded. Specifically, it's calling `request_firmware_direct` to grab the firmware itself, in this case, `MT7988_2P5GE_PMB_FW`, and then it uses `ioremap` to map it into memory at `MT7988_2P5GE_PMB_FW_BASE` with length `MT7988_2P5GE_PMB_FW_LEN`. Makes sense; fetch the firmware blob, get it into a known address space so the driver can work with it. Now, what's interesting is how it's *used*. I need to see how the driver actually *interacts* with this memory region. Let's see how the driver configures and works with this PHY. My next step will be to dive into `mtk-ge-soc.c` and specifically look at its probe function. I need to see how this firmware loading fits into the broader picture of initializing and configuring the 2.5G Ethernet PHY. |
| 28/2 | 2026/09/12 13:56 | tool | grepper |
0mArgs:{
"Expression": "\\.probe.*=",
"PathPrefix": "drivers/net/phy/mediatek/mtk-ge-soc.c"
}Results: {
"Output": "drivers/net/phy/mediatek/mtk-ge-soc.c=1495=static struct phy_driver mtk_socphy_driver[] = {\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1501-\t\t.handle_interrupt = genphy_handle_interrupt_no_ack,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1502:\t\t.probe\t\t= mt7981_phy_probe,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1503-\t\t.suspend\t= genphy_suspend,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1518-\t\t.handle_interrupt = genphy_handle_interrupt_no_ack,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1519:\t\t.probe\t\t= mt7988_phy_probe,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1520-\t\t.suspend\t= genphy_suspend,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1533-\t\t.config_init\t= en7528_phy_config_init,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1534:\t\t.probe\t\t= an7581_phy_probe,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1535-\t\t.led_blink_set\t= mt798x_phy_led_blink_set,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1546-\t\t.handle_interrupt = genphy_handle_interrupt_no_ack,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1547:\t\t.probe\t\t= an7581_phy_probe,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1548-\t\t.led_blink_set\t= mt798x_phy_led_blink_set,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1558-\t\t.config_init\t= an7583_phy_config_init,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1559:\t\t.probe\t\t= an7581_phy_probe,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1560-\t\t.led_blink_set\t= mt798x_phy_led_blink_set,\n"
} |
| 29/2 | 2026/09/12 13:56 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 23007 output: 46 thoughts: 37 Thoughts: Okay, here's my interpretation of those thoughts, presented as a first-person expert summary: **Probing the PHYs** Right, let's get down to brass tacks. I'm focusing on the PHY probe functions, specifically looking at `mt7981_phy_probe`, `mt7988_phy_probe`, and `an7581_phy_probe`. That means I'm in the process of identifying and initializing the physical layer (PHY) components associated with those specific chipsets. This probe function is the critical entry point; it's where the system discovers and configures the hardware. I'll need to scrutinize each of these. I'm looking for the distinct initialization sequences, any vendor-specific peculiarities, and, most importantly, how they integrate with the driver model. What's the resource allocation like? Are there any shared resources that could cause conflicts? I'll need to pay attention to the error handling within these probes as well, ensuring that the system can gracefully manage failed PHY detections and initializations. Ultimately, I'm expecting this is all about device discovery, resource allocation, and ensuring these PHYs are correctly brought up for use. |
| 30/2 | 2026/09/12 13:56 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/mediatek/mtk-ge-soc.c",
"FirstLine": 1410,
"LineCount": 85
}Results: {
"Contents": "1410:\t\n1411:\t\treturn mt798x_phy_calibration(phydev);\n1412:\t}\n1413:\t\n1414:\tstatic int mt7981_phy_probe(struct phy_device *phydev)\n1415:\t{\n1416:\t\tstruct mtk_socphy_priv *priv;\n1417:\t\n1418:\t\tpriv = devm_kzalloc(\u0026phydev-\u003emdio.dev, sizeof(struct mtk_socphy_priv),\n1419:\t\t\t\t GFP_KERNEL);\n1420:\t\tif (!priv)\n1421:\t\t\treturn -ENOMEM;\n1422:\t\n1423:\t\tphydev-\u003epriv = priv;\n1424:\t\n1425:\t\tmtk_phy_leds_state_init(phydev);\n1426:\t\n1427:\t\treturn mt798x_phy_calibration(phydev);\n1428:\t}\n1429:\t\n1430:\tstatic int an7581_phy_probe(struct phy_device *phydev)\n1431:\t{\n1432:\t\tstruct mtk_socphy_priv *priv;\n1433:\t\tstruct pinctrl *pinctrl;\n1434:\t\n1435:\t\t/* Toggle pinctrl to enable PHY LED */\n1436:\t\tpinctrl = devm_pinctrl_get_select(\u0026phydev-\u003emdio.dev, \"gbe-led\");\n1437:\t\tif (IS_ERR(pinctrl))\n1438:\t\t\tdev_err(\u0026phydev-\u003emdio.bus-\u003edev,\n1439:\t\t\t\t\"Failed to setup PHY LED pinctrl\\n\");\n1440:\t\n1441:\t\tpriv = devm_kzalloc(\u0026phydev-\u003emdio.dev, sizeof(*priv), GFP_KERNEL);\n1442:\t\tif (!priv)\n1443:\t\t\treturn -ENOMEM;\n1444:\t\n1445:\t\tphydev-\u003epriv = priv;\n1446:\t\n1447:\t\treturn 0;\n1448:\t}\n1449:\t\n1450:\tstatic int an7581_phy_led_polarity_set(struct phy_device *phydev, int index,\n1451:\t\t\t\t\t unsigned long modes)\n1452:\t{\n1453:\t\tu16 val = 0;\n1454:\t\tu32 mode;\n1455:\t\n1456:\t\tif (index \u003e= MTK_PHY_MAX_LEDS)\n1457:\t\t\treturn -EINVAL;\n1458:\t\n1459:\t\tfor_each_set_bit(mode, \u0026modes, __PHY_LED_MODES_NUM) {\n1460:\t\t\tswitch (mode) {\n1461:\t\t\tcase PHY_LED_ACTIVE_LOW:\n1462:\t\t\t\tval = MTK_PHY_LED_ON_POLARITY;\n1463:\t\t\t\tbreak;\n1464:\t\t\tcase PHY_LED_ACTIVE_HIGH:\n1465:\t\t\t\tbreak;\n1466:\t\t\tdefault:\n1467:\t\t\t\treturn -EINVAL;\n1468:\t\t\t}\n1469:\t\t}\n1470:\t\n1471:\t\treturn phy_modify_mmd(phydev, MDIO_MMD_VEND2, index ?\n1472:\t\t\t\t MTK_PHY_LED1_ON_CTRL : MTK_PHY_LED0_ON_CTRL,\n1473:\t\t\t\t MTK_PHY_LED_ON_POLARITY, val);\n1474:\t}\n1475:\t\n1476:\tstatic int an7583_phy_config_init(struct phy_device *phydev)\n1477:\t{\n1478:\t\t/* BMCR_PDOWN is enabled by default */\n1479:\t\treturn phy_clear_bits(phydev, MII_BMCR, BMCR_PDOWN);\n1480:\t}\n1481:\t\n1482:\tstatic int en7528_phy_config_init(struct phy_device *phydev)\n1483:\t{\n1484:\t\t/* The LED controller of the EN7528 powers up with its external\n1485:\t\t * control disabled, leaving the LED pins dark regardless of what is\n1486:\t\t * programmed into the LED control registers. Hand the pins over to\n1487:\t\t * the LED control registers the same way the air_en8811h driver\n1488:\t\t * does; the mode field of this register is already set out of reset.\n1489:\t\t */\n1490:\t\treturn phy_set_bits_mmd(phydev, MDIO_MMD_VEND2, MTK_PHY_LED_BCR,\n1491:\t\t\t\t\tMTK_PHY_LED_BCR_CLK_EN |\n1492:\t\t\t\t\tMTK_PHY_LED_BCR_EXT_CTRL);\n1493:\t}\n1494:\t\n"
} |
| 31/2 | 2026/09/12 13:56 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 24664 output: 29 thoughts: 40 Thoughts: **Investigating PHY LED Integration** Okay, hold on a second. I need to understand something here. Specifically, how are PHY LEDs, the physical layer interface LEDs, actually registered and handled within the kernel's LED subsystem? I'm missing a connection. The obvious places to start would be functions that *set* or *get* information about these LEDs. So, let's dive into the kernel source and perform a comprehensive search. I'll need to look for instances of `phy_led_set` and also `led_hw_control_get` in the entire kernel source tree. This should give me a good handle on how these elements are integrated. I'm hoping to understand the registration process, the control mechanisms, and how the underlying hardware interacts with the LED subsystem API. |
| 32/2 | 2026/09/12 13:56 | tool | grepper |
0mArgs:{
"Expression": "led_hw_control_get",
"PathPrefix": "drivers/"
}Results: {
"Output": "\nFull output is too long, showing 500 out of 660 lines.\nUse more precise expression if possible.\n\ndrivers/net/dsa/mv88e6xxx/leds.c=632=static int\ndrivers/net/dsa/mv88e6xxx/leds.c:633:mv88e6xxx_led_hw_control_get(struct mv88e6xxx_port *p, int led, unsigned long *rules)\ndrivers/net/dsa/mv88e6xxx/leds.c-634-{\n--\ndrivers/net/dsa/mv88e6xxx/leds.c=702=mv88e6xxx_led0_hw_control_get(struct led_classdev *ldev, unsigned long *rules)\n--\ndrivers/net/dsa/mv88e6xxx/leds.c-705-\ndrivers/net/dsa/mv88e6xxx/leds.c:706:\treturn mv88e6xxx_led_hw_control_get(p, 0, rules);\ndrivers/net/dsa/mv88e6xxx/leds.c-707-}\n--\ndrivers/net/dsa/mv88e6xxx/leds.c=710=mv88e6xxx_led1_hw_control_get(struct led_classdev *ldev, unsigned long *rules)\n--\ndrivers/net/dsa/mv88e6xxx/leds.c-713-\ndrivers/net/dsa/mv88e6xxx/leds.c:714:\treturn mv88e6xxx_led_hw_control_get(p, 1, rules);\ndrivers/net/dsa/mv88e6xxx/leds.c-715-}\ndrivers/net/dsa/mv88e6xxx/leds.c-716-\ndrivers/net/dsa/mv88e6xxx/leds.c:717:static struct device *mv88e6xxx_led_hw_control_get_device(struct mv88e6xxx_port *p)\ndrivers/net/dsa/mv88e6xxx/leds.c-718-{\n--\ndrivers/net/dsa/mv88e6xxx/leds.c=730=mv88e6xxx_led0_hw_control_get_device(struct led_classdev *ldev)\n--\ndrivers/net/dsa/mv88e6xxx/leds.c-733-\ndrivers/net/dsa/mv88e6xxx/leds.c:734:\treturn mv88e6xxx_led_hw_control_get_device(p);\ndrivers/net/dsa/mv88e6xxx/leds.c-735-}\n--\ndrivers/net/dsa/mv88e6xxx/leds.c=738=mv88e6xxx_led1_hw_control_get_device(struct led_classdev *ldev)\n--\ndrivers/net/dsa/mv88e6xxx/leds.c-741-\ndrivers/net/dsa/mv88e6xxx/leds.c:742:\treturn mv88e6xxx_led_hw_control_get_device(p);\ndrivers/net/dsa/mv88e6xxx/leds.c-743-}\n--\ndrivers/net/dsa/qca/qca8k-leds.c=309=static int\ndrivers/net/dsa/qca/qca8k-leds.c:310:qca8k_cled_hw_control_get(struct led_classdev *ldev, unsigned long *rules)\ndrivers/net/dsa/qca/qca8k-leds.c-311-{\n--\ndrivers/net/dsa/qca/qca8k-leds.c-349-\ndrivers/net/dsa/qca/qca8k-leds.c:350:static struct device *qca8k_cled_hw_control_get_device(struct led_classdev *ldev)\ndrivers/net/dsa/qca/qca8k-leds.c-351-{\n--\ndrivers/net/dsa/qca/qca8k-leds.c=365=qca8k_parse_port_leds(struct qca8k_priv *priv, struct fwnode_handle *port, int port_num)\n--\ndrivers/net/dsa/qca/qca8k-leds.c-424-\t\tport_led-\u003ecdev.hw_control_set = qca8k_cled_hw_control_set;\ndrivers/net/dsa/qca/qca8k-leds.c:425:\t\tport_led-\u003ecdev.hw_control_get = qca8k_cled_hw_control_get;\ndrivers/net/dsa/qca/qca8k-leds.c:426:\t\tport_led-\u003ecdev.hw_control_get_device = qca8k_cled_hw_control_get_device;\ndrivers/net/dsa/qca/qca8k-leds.c-427-\t\tport_led-\u003ecdev.hw_control_trigger = \"netdev\";\n--\ndrivers/net/ethernet/intel/igc/igc_leds.c=162=static int igc_led_hw_control_set(struct led_classdev *led_cdev,\n--\ndrivers/net/ethernet/intel/igc/igc_leds.c-193-\ndrivers/net/ethernet/intel/igc/igc_leds.c:194:static int igc_led_hw_control_get(struct led_classdev *led_cdev,\ndrivers/net/ethernet/intel/igc/igc_leds.c-195-\t\t\t\t unsigned long *flags)\n--\ndrivers/net/ethernet/intel/igc/igc_leds.c-223-\ndrivers/net/ethernet/intel/igc/igc_leds.c:224:static struct device *igc_led_hw_control_get_device(struct led_classdev *led_cdev)\ndrivers/net/ethernet/intel/igc/igc_leds.c-225-{\n--\ndrivers/net/ethernet/intel/igc/igc_leds.c=239=static int igc_setup_ldev(struct igc_led_classdev *ldev,\n--\ndrivers/net/ethernet/intel/igc/igc_leds.c-256-\tled_cdev-\u003ehw_control_set = igc_led_hw_control_set;\ndrivers/net/ethernet/intel/igc/igc_leds.c:257:\tled_cdev-\u003ehw_control_get = igc_led_hw_control_get;\ndrivers/net/ethernet/intel/igc/igc_leds.c:258:\tled_cdev-\u003ehw_control_get_device = igc_led_hw_control_get_device;\ndrivers/net/ethernet/intel/igc/igc_leds.c-259-\n--\ndrivers/net/ethernet/realtek/r8169_leds.c=70=static int rtl8168_led_hw_control_set(struct led_classdev *led_cdev,\n--\ndrivers/net/ethernet/realtek/r8169_leds.c-89-\ndrivers/net/ethernet/realtek/r8169_leds.c:90:static int rtl8168_led_hw_control_get(struct led_classdev *led_cdev,\ndrivers/net/ethernet/realtek/r8169_leds.c-91-\t\t\t\t unsigned long *flags)\n--\ndrivers/net/ethernet/realtek/r8169_leds.c=122=static struct device *\ndrivers/net/ethernet/realtek/r8169_leds.c:123:\tr8169_led_hw_control_get_device(struct led_classdev *led_cdev)\ndrivers/net/ethernet/realtek/r8169_leds.c-124-{\n--\ndrivers/net/ethernet/realtek/r8169_leds.c=130=static void rtl8168_setup_ldev(struct r8169_led_classdev *ldev,\n--\ndrivers/net/ethernet/realtek/r8169_leds.c-144-\tled_cdev-\u003ehw_control_set = rtl8168_led_hw_control_set;\ndrivers/net/ethernet/realtek/r8169_leds.c:145:\tled_cdev-\u003ehw_control_get = rtl8168_led_hw_control_get;\ndrivers/net/ethernet/realtek/r8169_leds.c:146:\tled_cdev-\u003ehw_control_get_device = r8169_led_hw_control_get_device;\ndrivers/net/ethernet/realtek/r8169_leds.c-147-\n--\ndrivers/net/ethernet/realtek/r8169_leds.c=182=static int rtl8125_led_hw_control_set(struct led_classdev *led_cdev,\n--\ndrivers/net/ethernet/realtek/r8169_leds.c-202-\ndrivers/net/ethernet/realtek/r8169_leds.c:203:static int rtl8125_led_hw_control_get(struct led_classdev *led_cdev,\ndrivers/net/ethernet/realtek/r8169_leds.c-204-\t\t\t\t unsigned long *flags)\n--\ndrivers/net/ethernet/realtek/r8169_leds.c=228=static void rtl8125_setup_led_ldev(struct r8169_led_classdev *ldev,\n--\ndrivers/net/ethernet/realtek/r8169_leds.c-242-\tled_cdev-\u003ehw_control_set = rtl8125_led_hw_control_set;\ndrivers/net/ethernet/realtek/r8169_leds.c:243:\tled_cdev-\u003ehw_control_get = rtl8125_led_hw_control_get;\ndrivers/net/ethernet/realtek/r8169_leds.c:244:\tled_cdev-\u003ehw_control_get_device = r8169_led_hw_control_get_device;\ndrivers/net/ethernet/realtek/r8169_leds.c-245-\n--\ndrivers/net/phy/air_an8801.c=333=static int an8801r_led_brightness_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/air_an8801.c-356-\ndrivers/net/phy/air_an8801.c:357:static int an8801r_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/air_an8801.c-358-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/air_an8801.c=1122=static struct phy_driver airoha_driver[] = {\n--\ndrivers/net/phy/air_an8801.c-1142-\t.led_hw_control_set\t= an8801r_led_hw_control_set,\ndrivers/net/phy/air_an8801.c:1143:\t.led_hw_control_get\t= an8801r_led_hw_control_get,\ndrivers/net/phy/air_an8801.c-1144-\t.led_polarity_set\t= an8801r_led_polarity_set,\n--\ndrivers/net/phy/air_en8811h.c=670=static int air_led_brightness_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/air_en8811h.c-694-\ndrivers/net/phy/air_en8811h.c:695:static int air_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/air_en8811h.c-696-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/air_en8811h.c=1512=static struct phy_driver en8811h_driver[] = {\n--\ndrivers/net/phy/air_en8811h.c-1531-\t.led_hw_control_set\t= air_led_hw_control_set,\ndrivers/net/phy/air_en8811h.c:1532:\t.led_hw_control_get\t= air_led_hw_control_get,\ndrivers/net/phy/air_en8811h.c-1533-},\n--\ndrivers/net/phy/air_en8811h.c-1553-\t.led_hw_control_set\t= air_led_hw_control_set,\ndrivers/net/phy/air_en8811h.c:1554:\t.led_hw_control_get\t= air_led_hw_control_get,\ndrivers/net/phy/air_en8811h.c-1555-} };\n--\ndrivers/net/phy/aquantia/aquantia.h=248=int aqr_phy_led_hw_is_supported(struct phy_device *phydev, u8 index,\ndrivers/net/phy/aquantia/aquantia.h-249-\t\t\t\tunsigned long rules);\ndrivers/net/phy/aquantia/aquantia.h:250:int aqr_phy_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/aquantia/aquantia.h-251-\t\t\t unsigned long *rules);\n--\ndrivers/net/phy/aquantia/aquantia_leds.c=34=int aqr_phy_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/aquantia/aquantia_leds.c-46-\ndrivers/net/phy/aquantia/aquantia_leds.c:47:int aqr_phy_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/aquantia/aquantia_leds.c-48-\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/aquantia/aquantia_main.c=1181=static struct phy_driver aqr_driver[] = {\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1239-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1240:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1241-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1266-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1267:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1268-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1293-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1294:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1295-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1320-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1321:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1322-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1356-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1357:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1358-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1424-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1425:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1426-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1450-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1451:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1452-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1477-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1478:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1479-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1504-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1505:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1506-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1531-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1532:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1533-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1557-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1558:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1559-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c=788=static int as21xxx_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/as21xxx.c-802-\ndrivers/net/phy/as21xxx.c:803:static int as21xxx_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/as21xxx.c-804-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/as21xxx.c=946=static struct phy_driver as21xxx_drivers[] = {\n--\ndrivers/net/phy/as21xxx.c-965-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:966:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-967-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-977-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:978:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-979-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-989-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:990:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-991-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1001-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1002:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1003-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1013-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1014:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1015-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1025-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1026:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1027-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1037-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1038:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1039-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1049-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1050:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1051-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1061-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1062:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1063-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1073-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1074:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1075-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/bcm84881.c=158=static int bcm8489x_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/bcm84881.c-183-\ndrivers/net/phy/bcm84881.c:184:static int bcm8489x_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/bcm84881.c-185-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/bcm84881.c=419=static struct phy_driver bcm84881_drivers[] = {\n--\ndrivers/net/phy/bcm84881.c-443-\t\t.led_hw_control_set = bcm8489x_led_hw_control_set,\ndrivers/net/phy/bcm84881.c:444:\t\t.led_hw_control_get = bcm8489x_led_hw_control_get,\ndrivers/net/phy/bcm84881.c-445-\t}, {\n--\ndrivers/net/phy/bcm84881.c-457-\t\t.led_hw_control_set = bcm8489x_led_hw_control_set,\ndrivers/net/phy/bcm84881.c:458:\t\t.led_hw_control_get = bcm8489x_led_hw_control_get,\ndrivers/net/phy/bcm84881.c-459-\t},\n--\ndrivers/net/phy/dp83822.c=1097=static int dp83822_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/dp83822.c-1123-\ndrivers/net/phy/dp83822.c:1124:static int dp83822_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/dp83822.c-1125-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/dp83822.c-1199-\t\t.led_hw_control_set = dp83822_led_hw_control_set,\t\\\ndrivers/net/phy/dp83822.c:1200:\t\t.led_hw_control_get = dp83822_led_hw_control_get,\t\\\ndrivers/net/phy/dp83822.c-1201-\t\t.attach_mdi_port = dp83822_attach_mdi_port\t\t\\\n--\ndrivers/net/phy/dp83867.c=1069=static int dp83867_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/dp83867.c-1085-\ndrivers/net/phy/dp83867.c:1086:static int dp83867_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/dp83867.c-1087-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/dp83867.c=1183=static struct phy_driver dp83867_driver[] = {\n--\ndrivers/net/phy/dp83867.c-1214-\t\t.led_hw_control_set = dp83867_led_hw_control_set,\ndrivers/net/phy/dp83867.c:1215:\t\t.led_hw_control_get = dp83867_led_hw_control_get,\ndrivers/net/phy/dp83867.c-1216-\t\t.led_polarity_set = dp83867_led_polarity_set,\n--\ndrivers/net/phy/dp83td510.c=367=static int dp83td510_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/dp83td510.c-385-\ndrivers/net/phy/dp83td510.c:386:static int dp83td510_led_hw_control_get(struct phy_device *phydev,\ndrivers/net/phy/dp83td510.c-387-\t\t\t\t\tu8 index, unsigned long *rules)\n--\ndrivers/net/phy/dp83td510.c=939=static struct phy_driver dp83td510_driver[] = {\n--\ndrivers/net/phy/dp83td510.c-963-\t.led_hw_control_set = dp83td510_led_hw_control_set,\ndrivers/net/phy/dp83td510.c:964:\t.led_hw_control_get = dp83td510_led_hw_control_get,\ndrivers/net/phy/dp83td510.c-965-\t.led_polarity_set = dp83td510_led_polarity_set,\n--\ndrivers/net/phy/intel-xway.c=428=static int xway_gphy_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/intel-xway.c-450-\ndrivers/net/phy/intel-xway.c:451:static int xway_gphy_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/intel-xway.c-452-\t\t\t\t\tunsigned long *rules)\n--\ndrivers/net/phy/intel-xway.c=584=static struct phy_driver xway_gphy[] = {\n--\ndrivers/net/phy/intel-xway.c-598-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:599:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-600-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-617-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:618:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-619-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-636-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:637:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-638-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-655-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:656:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-657-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-673-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:674:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-675-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-691-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:692:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-693-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-709-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:710:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-711-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-727-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:728:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-729-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-745-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:746:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-747-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-763-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:764:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-765-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/marvell-88q2xxx.c=1040=static int mv88q2xxx_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/marvell-88q2xxx.c-1062-\ndrivers/net/phy/marvell-88q2xxx.c:1063:static int mv88q2xxx_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/marvell-88q2xxx.c-1064-\t\t\t\t\tunsigned long *rules)\n--\ndrivers/net/phy/marvell-88q2xxx.c=1102=static struct phy_driver mv88q2xxx_driver[] = {\n--\ndrivers/net/phy/marvell-88q2xxx.c-1139-\t\t.led_hw_control_set\t= mv88q2xxx_led_hw_control_set,\ndrivers/net/phy/marvell-88q2xxx.c:1140:\t\t.led_hw_control_get\t= mv88q2xxx_led_hw_control_get,\ndrivers/net/phy/marvell-88q2xxx.c-1141-\t},\n--\ndrivers/net/phy/marvell.c=3541=static int m88e1318_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/marvell.c-3569-\ndrivers/net/phy/marvell.c:3570:static int m88e1318_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/marvell.c-3571-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/marvell.c=3667=static struct phy_driver marvell_drivers[] = {\n--\ndrivers/net/phy/marvell.c-3834-\t\t.led_hw_control_set = m88e1318_led_hw_control_set,\ndrivers/net/phy/marvell.c:3835:\t\t.led_hw_control_get = m88e1318_led_hw_control_get,\ndrivers/net/phy/marvell.c-3836-\t},\n--\ndrivers/net/phy/marvell.c-3948-\t\t.led_hw_control_set = m88e1318_led_hw_control_set,\ndrivers/net/phy/marvell.c:3949:\t\t.led_hw_control_get = m88e1318_led_hw_control_get,\ndrivers/net/phy/marvell.c-3950-\t\t.attach_mii_port = m88e1510_attach_mii_port,\n--\ndrivers/net/phy/marvell.c-3980-\t\t.led_hw_control_set = m88e1318_led_hw_control_set,\ndrivers/net/phy/marvell.c:3981:\t\t.led_hw_control_get = m88e1318_led_hw_control_get,\ndrivers/net/phy/marvell.c-3982-\t},\n--\ndrivers/net/phy/marvell.c-4011-\t\t.led_hw_control_set = m88e1318_led_hw_control_set,\ndrivers/net/phy/marvell.c:4012:\t\t.led_hw_control_get = m88e1318_led_hw_control_get,\ndrivers/net/phy/marvell.c-4013-\t},\n--\ndrivers/net/phy/marvell.c-4172-\t\t.led_hw_control_set = m88e1318_led_hw_control_set,\ndrivers/net/phy/marvell.c:4173:\t\t.led_hw_control_get = m88e1318_led_hw_control_get,\ndrivers/net/phy/marvell.c-4174-\t},\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c=298=static int mt798x_2p5ge_phy_led_hw_is_supported(struct phy_device *phydev,\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c-304-\ndrivers/net/phy/mediatek/mtk-2p5ge.c:305:static int mt798x_2p5ge_phy_led_hw_control_get(struct phy_device *phydev,\ndrivers/net/phy/mediatek/mtk-2p5ge.c-306-\t\t\t\t\t u8 index, unsigned long *rules)\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c=379=static struct phy_driver mtk_2p5gephy_driver[] = {\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c-395-\t\t.led_hw_is_supported = mt798x_2p5ge_phy_led_hw_is_supported,\ndrivers/net/phy/mediatek/mtk-2p5ge.c:396:\t\t.led_hw_control_get = mt798x_2p5ge_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-2p5ge.c-397-\t\t.led_hw_control_set = mt798x_2p5ge_phy_led_hw_control_set,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c=1269=static int mt798x_phy_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1275-\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1276:static int mt798x_phy_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1277-\t\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c=1495=static struct phy_driver mtk_socphy_driver[] = {\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1510-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1511:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1512-\t},\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1527-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1528:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1529-\t},\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1538-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1539:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1540-\t\t.led_polarity_set = an7581_phy_led_polarity_set,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1551-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1552:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1553-\t\t.led_polarity_set = an7581_phy_led_polarity_set,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1563-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1564:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1565-\t\t.led_polarity_set = an7581_phy_led_polarity_set,\n--\ndrivers/net/phy/mediatek/mtk-phy-lib.c=342=void mtk_phy_leds_state_init(struct phy_device *phydev)\n--\ndrivers/net/phy/mediatek/mtk-phy-lib.c-346-\tfor (i = 0; i \u003c 2; ++i)\ndrivers/net/phy/mediatek/mtk-phy-lib.c:347:\t\tphydev-\u003edrv-\u003eled_hw_control_get(phydev, i, NULL);\ndrivers/net/phy/mediatek/mtk-phy-lib.c-348-}\n--\ndrivers/net/phy/motorcomm.c=1752=static int yt8521_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/motorcomm.c-1793-\ndrivers/net/phy/motorcomm.c:1794:static int yt8521_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/motorcomm.c-1795-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/motorcomm.c=3075=static struct phy_driver motorcomm_phy_drvs[] = {\n--\ndrivers/net/phy/motorcomm.c-3102-\t\t.led_hw_control_set = yt8521_led_hw_control_set,\ndrivers/net/phy/motorcomm.c:3103:\t\t.led_hw_control_get = yt8521_led_hw_control_get,\ndrivers/net/phy/motorcomm.c-3104-\t},\n--\ndrivers/net/phy/motorcomm.c-3124-\t\t.led_hw_control_set = yt8521_led_hw_control_set,\ndrivers/net/phy/motorcomm.c:3125:\t\t.led_hw_control_get = yt8521_led_hw_control_get,\ndrivers/net/phy/motorcomm.c-3126-\t},\n--\ndrivers/net/phy/mscc/mscc_main.c=2330=static int vsc85xx_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/mscc/mscc_main.c-2349-\ndrivers/net/phy/mscc/mscc_main.c:2350:static int vsc85xx_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mscc/mscc_main.c-2351-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/mscc/mscc_main.c=2548=static struct phy_driver vsc85xx_driver[] = {\n--\ndrivers/net/phy/mscc/mscc_main.c-2573-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2574:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2575-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2601-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2602:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2603-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2632-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2633:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2634-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2661-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2662:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2663-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2689-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2690:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2691-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2717-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2718:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2719-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2745-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2746:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2747-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2773-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2774:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2775-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2803-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2804:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2805-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2830-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2831:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2832-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2862-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2863:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2864-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2894-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2895:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2896-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2923-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2924:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2925-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2952-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2953:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2954-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2982-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2983:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2984-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mxl-86110.c=438=static int mxl86110_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/mxl-86110.c-450-\ndrivers/net/phy/mxl-86110.c:451:static int mxl86110_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mxl-86110.c-452-\t\t\t\t unsigned long *rules)\n--\n\n"
} |
| 33/2 | 2026/09/12 13:56 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 39857 output: 45 thoughts: 81 Thoughts: Here's my summary, as though I were thinking through the problem: **Diving into the MTK PHY LED Initialization** Okay, so I'm digging into this `mtk-phy-lib.c` file again. Specifically, I'm tracing the LED initialization process for this MTK PHY. I know from experience these drivers can be a bit… delicate. I'm focusing on the `mtk_phy_leds_state_init()` function right now. I see a call to `phydev->drv->led_hw_control_get(phydev, i, NULL);`. That's where the driver is supposed to be pulling the LED hardware control status, right? It's likely getting the initial state. I'm going to have to check what `led_hw_control_get` actually *does* within the MTK context. Line 342, here I come! Let's see if I can understand how the PHY's state is being set. I hope the documentation's up to par... |
| 34/2 | 2026/09/12 13:56 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/mediatek/mtk-phy-lib.c",
"FirstLine": 320,
"LineCount": 40
}Results: {
"Contents": " 320:\t\t\t\t\t (index ? 16 : 0);\n 321:\t\tstruct mtk_socphy_priv *priv = phydev-\u003epriv;\n 322:\t\tbool changed;\n 323:\t\n 324:\t\tif (blinking)\n 325:\t\t\tchanged = !test_and_set_bit(bit_blink, \u0026priv-\u003eled_state);\n 326:\t\telse\n 327:\t\t\tchanged = !!test_and_clear_bit(bit_blink, \u0026priv-\u003eled_state);\n 328:\t\n 329:\t\tchanged |= !!test_bit(MTK_PHY_LED_STATE_NETDEV +\n 330:\t\t\t\t (index ? 16 : 0), \u0026priv-\u003eled_state);\n 331:\t\tif (changed)\n 332:\t\t\treturn phy_write_mmd(phydev, MDIO_MMD_VEND2, index ?\n 333:\t\t\t\t\t MTK_PHY_LED1_BLINK_CTRL :\n 334:\t\t\t\t\t MTK_PHY_LED0_BLINK_CTRL,\n 335:\t\t\t\t\t blinking ?\n 336:\t\t\t\t\t MTK_PHY_LED_BLINK_FORCE_BLINK : 0);\n 337:\t\telse\n 338:\t\t\treturn 0;\n 339:\t}\n 340:\tEXPORT_SYMBOL_GPL(mtk_phy_hw_led_blink_set);\n 341:\t\n 342:\tvoid mtk_phy_leds_state_init(struct phy_device *phydev)\n 343:\t{\n 344:\t\tint i;\n 345:\t\n 346:\t\tfor (i = 0; i \u003c 2; ++i)\n 347:\t\t\tphydev-\u003edrv-\u003eled_hw_control_get(phydev, i, NULL);\n 348:\t}\n 349:\tEXPORT_SYMBOL_GPL(mtk_phy_leds_state_init);\n 350:\t\n 351:\tMODULE_DESCRIPTION(\"MediaTek Ethernet PHY driver common\");\n 352:\tMODULE_AUTHOR(\"Sky Huang \u003cSkyLake.Huang@mediatek.com\u003e\");\n 353:\tMODULE_AUTHOR(\"Daniel Golle \u003cdaniel@makrotopia.org\u003e\");\n 354:\tMODULE_LICENSE(\"GPL\");\n"
} |
| 35/2 | 2026/09/12 13:56 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 40816 output: 38 thoughts: 60 Thoughts: **Investigating the LED Hardware Control Flow** Okay, hold on a second! I need to trace this `phydev->drv->led_hw_control_get` call within the core network/LED subsystem. It's crucial to understand where this function, `led_hw_control_get`, is actually invoked. My instinct tells me it's probably somewhere within the `drivers/net/phy/phy_device.c` file, or perhaps scattered throughout other related network driver code. Time to dig in and find those call sites. This is key to understanding how the hardware LED control is being managed, and any issues related to its configuration. Let's get cracking! |
| 36/2 | 2026/09/12 13:56 | tool | grepper |
0mArgs:{
"Expression": "led_hw_control_get",
"PathPrefix": "drivers/net/phy/phy_device.c"
}Results: {
"Output": "drivers/net/phy/phy_device.c=3261=static __maybe_unused struct device *\ndrivers/net/phy/phy_device.c:3262:phy_led_hw_control_get_device(struct led_classdev *led_cdev)\ndrivers/net/phy/phy_device.c-3263-{\n--\ndrivers/net/phy/phy_device.c=3272=static int __maybe_unused\ndrivers/net/phy/phy_device.c:3273:phy_led_hw_control_get(struct led_classdev *led_cdev,\ndrivers/net/phy/phy_device.c-3274-\t\t unsigned long *rules)\n--\ndrivers/net/phy/phy_device.c-3280-\tmutex_lock(\u0026phydev-\u003elock);\ndrivers/net/phy/phy_device.c:3281:\terr = phydev-\u003edrv-\u003eled_hw_control_get(phydev, phyled-\u003eindex, rules);\ndrivers/net/phy/phy_device.c-3282-\tmutex_unlock(\u0026phydev-\u003elock);\n--\ndrivers/net/phy/phy_device.c=3326=static int of_phy_led(struct phy_device *phydev,\n--\ndrivers/net/phy/phy_device.c-3379-\t phydev-\u003edrv-\u003eled_hw_control_set \u0026\u0026\ndrivers/net/phy/phy_device.c:3380:\t phydev-\u003edrv-\u003eled_hw_control_get) {\ndrivers/net/phy/phy_device.c-3381-\t\tcdev-\u003ehw_control_is_supported = phy_led_hw_is_supported;\ndrivers/net/phy/phy_device.c-3382-\t\tcdev-\u003ehw_control_set = phy_led_hw_control_set;\ndrivers/net/phy/phy_device.c:3383:\t\tcdev-\u003ehw_control_get = phy_led_hw_control_get;\ndrivers/net/phy/phy_device.c-3384-\t\tcdev-\u003ehw_control_trigger = \"netdev\";\n--\ndrivers/net/phy/phy_device.c-3386-\ndrivers/net/phy/phy_device.c:3387:\tcdev-\u003ehw_control_get_device = phy_led_hw_control_get_device;\ndrivers/net/phy/phy_device.c-3388-#endif\n"
} |
| 37/2 | 2026/09/12 13:56 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 41680 output: 40 thoughts: 37 Thoughts: Here's my take on those thoughts, from an expert's perspective: **Diving into the PHY LED Implementation** Okay, so I see `of_phy_led` – that's intriguing. My intuition tells me we're looking at something related to LED control tied to the PHY (Physical Layer) of a network device, likely driven by device tree bindings. I'm immediately thinking, "Let's check out where this is defined and used." The obvious place to start is within the core PHY driver code, specifically `drivers/net/phy/phy_device.c`. That's where I'd expect to find the meat of the PHY device management logic and, hopefully, how these LEDs are initialized and handled. Let's see what the code tells us about how it's done. I bet there's some device tree parsing involved and I am interested to understand how this ties into the interrupt handling or polling (if it exists) from the PHY itself. Time to dig in! |
| 38/2 | 2026/09/12 13:56 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/phy_device.c",
"FirstLine": 3325,
"LineCount": 75
}Results: {
"Contents": "3325:\t\n3326:\tstatic int of_phy_led(struct phy_device *phydev,\n3327:\t\t\t struct device_node *led)\n3328:\t{\n3329:\t\tstruct device *dev = \u0026phydev-\u003emdio.dev;\n3330:\t\tstruct led_init_data init_data = {};\n3331:\t\tstruct led_classdev *cdev;\n3332:\t\tunsigned long modes = 0;\n3333:\t\tstruct phy_led *phyled;\n3334:\t\tu32 index;\n3335:\t\tint err;\n3336:\t\n3337:\t\tphyled = devm_kzalloc(dev, sizeof(*phyled), GFP_KERNEL);\n3338:\t\tif (!phyled)\n3339:\t\t\treturn -ENOMEM;\n3340:\t\n3341:\t\tcdev = \u0026phyled-\u003eled_cdev;\n3342:\t\tphyled-\u003ephydev = phydev;\n3343:\t\n3344:\t\terr = of_property_read_u32(led, \"reg\", \u0026index);\n3345:\t\tif (err)\n3346:\t\t\treturn err;\n3347:\t\tif (index \u003e U8_MAX)\n3348:\t\t\treturn -EINVAL;\n3349:\t\n3350:\t\tif (of_property_read_bool(led, \"active-high\"))\n3351:\t\t\tset_bit(PHY_LED_ACTIVE_HIGH, \u0026modes);\n3352:\t\tif (of_property_read_bool(led, \"active-low\"))\n3353:\t\t\tset_bit(PHY_LED_ACTIVE_LOW, \u0026modes);\n3354:\t\tif (of_property_read_bool(led, \"inactive-high-impedance\"))\n3355:\t\t\tset_bit(PHY_LED_INACTIVE_HIGH_IMPEDANCE, \u0026modes);\n3356:\t\n3357:\t\tif (WARN_ON(modes \u0026 BIT(PHY_LED_ACTIVE_LOW) \u0026\u0026\n3358:\t\t\t modes \u0026 BIT(PHY_LED_ACTIVE_HIGH)))\n3359:\t\t\treturn -EINVAL;\n3360:\t\n3361:\t\tif (modes) {\n3362:\t\t\t/* Return error if asked to set polarity modes but not supported */\n3363:\t\t\tif (!phydev-\u003edrv-\u003eled_polarity_set)\n3364:\t\t\t\treturn -EINVAL;\n3365:\t\n3366:\t\t\terr = phydev-\u003edrv-\u003eled_polarity_set(phydev, index, modes);\n3367:\t\t\tif (err)\n3368:\t\t\t\treturn err;\n3369:\t\t}\n3370:\t\n3371:\t\tphyled-\u003eindex = index;\n3372:\t\tif (phydev-\u003edrv-\u003eled_brightness_set)\n3373:\t\t\tcdev-\u003ebrightness_set_blocking = phy_led_set_brightness;\n3374:\t\tif (phydev-\u003edrv-\u003eled_blink_set)\n3375:\t\t\tcdev-\u003eblink_set = phy_led_blink_set;\n3376:\t\n3377:\t#ifdef CONFIG_LEDS_TRIGGERS\n3378:\t\tif (phydev-\u003edrv-\u003eled_hw_is_supported \u0026\u0026\n3379:\t\t phydev-\u003edrv-\u003eled_hw_control_set \u0026\u0026\n3380:\t\t phydev-\u003edrv-\u003eled_hw_control_get) {\n3381:\t\t\tcdev-\u003ehw_control_is_supported = phy_led_hw_is_supported;\n3382:\t\t\tcdev-\u003ehw_control_set = phy_led_hw_control_set;\n3383:\t\t\tcdev-\u003ehw_control_get = phy_led_hw_control_get;\n3384:\t\t\tcdev-\u003ehw_control_trigger = \"netdev\";\n3385:\t\t}\n3386:\t\n3387:\t\tcdev-\u003ehw_control_get_device = phy_led_hw_control_get_device;\n3388:\t#endif\n3389:\t\tcdev-\u003emax_brightness = 1;\n3390:\t\tinit_data.devicename = dev_name(\u0026phydev-\u003emdio.dev);\n3391:\t\tinit_data.fwnode = of_fwnode_handle(led);\n3392:\t\tinit_data.devname_mandatory = true;\n3393:\t\n3394:\t\terr = led_classdev_register_ext(dev, cdev, \u0026init_data);\n3395:\t\tif (err)\n3396:\t\t\treturn err;\n3397:\t\n3398:\t\tlist_add(\u0026phyled-\u003elist, \u0026phydev-\u003eleds);\n3399:\t\n"
} |
| 39/2 | 2026/09/12 13:56 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 43207 output: 30 thoughts: 50 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: **Analyzing the `of_phy_led` Function and Device Tree Dependence** Right, let's break this down. My initial observation is that `of_phy_led` is expecting a `struct device_node *led` as an argument. That immediately tells me this function is deeply intertwined with Device Tree, which, of course, implies Open Firmware (or, if we're feeling pedantic, Flattened Device Tree) is the configuration paradigm at play here. Good, a clear signal right off the bat. Now, I need to understand the implications of that dependency. Specifically, I need to track the calls to this function so I can determine what it does, and which parts of the DT configuration it's using. |
| 40/2 | 2026/09/12 13:56 | tool | grepper |
0mArgs:{
"Expression": "of_phy_led",
"PathPrefix": "drivers/net/phy"
}Results: {
"Output": "drivers/net/phy/phy_device.c=3316=static void phy_leds_unregister(struct phy_device *phydev)\n--\ndrivers/net/phy/phy_device.c-3325-\ndrivers/net/phy/phy_device.c:3326:static int of_phy_led(struct phy_device *phydev,\ndrivers/net/phy/phy_device.c-3327-\t\t struct device_node *led)\n--\ndrivers/net/phy/phy_device.c-3402-\ndrivers/net/phy/phy_device.c:3403:static int of_phy_leds(struct phy_device *phydev)\ndrivers/net/phy/phy_device.c-3404-{\n--\ndrivers/net/phy/phy_device.c-3429-\tfor_each_available_child_of_node_scoped(leds, led) {\ndrivers/net/phy/phy_device.c:3430:\t\terr = of_phy_led(phydev, led);\ndrivers/net/phy/phy_device.c-3431-\t\tif (err) {\n--\ndrivers/net/phy/phy_device.c=3685=static int phy_probe(struct device *dev)\n--\ndrivers/net/phy/phy_device.c-3806-\tif (IS_ENABLED(CONFIG_PHYLIB_LEDS) \u0026\u0026 !phy_driver_is_genphy(phydev)) {\ndrivers/net/phy/phy_device.c:3807:\t\terr = of_phy_leds(phydev);\ndrivers/net/phy/phy_device.c-3808-\t\tif (err)\n"
} |
| 41/2 | 2026/09/12 13:56 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 43890 output: 45 thoughts: 395 Thoughts: **My Investigation into PHY LED Initialization**
Okay, so `of_phy_leds(phydev)` is only ever called during `phy_probe()`. And, as I recall, it requires Device Tree information using `of_get_child_by_name(dev->of_node, "leds")`. But something feels off... what about `mtk_phy_leds_state_init(phydev)`? Where does that get called?
Aha! It's in `drivers/net/phy/mediatek/mtk-phy-lib.c`. Let me take a look at it:
```c
void mtk_phy_leds_state_init(struct phy_device *phydev)
{
int i;
for (i = 0; i < 2; ++i)
phydev->drv->led_hw_control_get(phydev, i, NULL);
}
```
Wait a minute, I see it! `mtk_phy_leds_state_init` gets called directly within `mt798x_2p5ge_phy_probe` and `mt7981_phy_probe`. That's important.
Now, let's trace this back to the `mtk_phy_led_hw_ctrl_get` function. Digging into the same `mtk-phy-lib.c` file, I see:
```c
int mtk_phy_led_hw_ctrl_get(struct phy_device *phydev, u8 index,
unsigned long *rules, u16 on_set,
u16 rx_blink_set, u16 tx_blink_set)
{
...
if (!rules)
return 0;
```
Interesting, specifically looking at `mtk_phy_led_hw_ctrl_get` when called from `mtk_phy_leds_state_init`, the `rules` pointer is NULL. That seems like a potential point of interest. I should really trace the logic flow more closely within `drivers/net/phy/mediatek/mtk-phy-lib.c` from lines 113 to 200, which is where this function is implemented, to see what that *means*.
|
| 42/2 | 2026/09/12 13:56 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/mediatek/mtk-phy-lib.c",
"FirstLine": 113,
"LineCount": 85
}Results: {
"Contents": " 113:\tint mtk_phy_led_hw_ctrl_get(struct phy_device *phydev, u8 index,\n 114:\t\t\t\t unsigned long *rules, u16 on_set,\n 115:\t\t\t\t u16 rx_blink_set, u16 tx_blink_set)\n 116:\t{\n 117:\t\tunsigned int bit_blink = MTK_PHY_LED_STATE_FORCE_BLINK +\n 118:\t\t\t\t\t (index ? 16 : 0);\n 119:\t\tunsigned int bit_netdev = MTK_PHY_LED_STATE_NETDEV + (index ? 16 : 0);\n 120:\t\tunsigned int bit_on = MTK_PHY_LED_STATE_FORCE_ON + (index ? 16 : 0);\n 121:\t\tstruct mtk_socphy_priv *priv = phydev-\u003epriv;\n 122:\t\tint on, blink;\n 123:\t\n 124:\t\tif (index \u003e 1)\n 125:\t\t\treturn -EINVAL;\n 126:\t\n 127:\t\ton = phy_read_mmd(phydev, MDIO_MMD_VEND2,\n 128:\t\t\t\t index ? MTK_PHY_LED1_ON_CTRL : MTK_PHY_LED0_ON_CTRL);\n 129:\t\n 130:\t\tif (on \u003c 0)\n 131:\t\t\treturn -EIO;\n 132:\t\n 133:\t\tblink = phy_read_mmd(phydev, MDIO_MMD_VEND2,\n 134:\t\t\t\t index ? MTK_PHY_LED1_BLINK_CTRL :\n 135:\t\t\t\t\t MTK_PHY_LED0_BLINK_CTRL);\n 136:\t\tif (blink \u003c 0)\n 137:\t\t\treturn -EIO;\n 138:\t\n 139:\t\tif ((on \u0026 (on_set | MTK_PHY_LED_ON_FDX |\n 140:\t\t\t MTK_PHY_LED_ON_HDX | MTK_PHY_LED_ON_LINKDOWN)) ||\n 141:\t\t (blink \u0026 (rx_blink_set | tx_blink_set)))\n 142:\t\t\tset_bit(bit_netdev, \u0026priv-\u003eled_state);\n 143:\t\telse\n 144:\t\t\tclear_bit(bit_netdev, \u0026priv-\u003eled_state);\n 145:\t\n 146:\t\tif (on \u0026 MTK_PHY_LED_ON_FORCE_ON)\n 147:\t\t\tset_bit(bit_on, \u0026priv-\u003eled_state);\n 148:\t\telse\n 149:\t\t\tclear_bit(bit_on, \u0026priv-\u003eled_state);\n 150:\t\n 151:\t\tif (blink \u0026 MTK_PHY_LED_BLINK_FORCE_BLINK)\n 152:\t\t\tset_bit(bit_blink, \u0026priv-\u003eled_state);\n 153:\t\telse\n 154:\t\t\tclear_bit(bit_blink, \u0026priv-\u003eled_state);\n 155:\t\n 156:\t\tif (!rules)\n 157:\t\t\treturn 0;\n 158:\t\n 159:\t\t/* TRIGGER_NETDEV_LINK must not be reported together with any of the\n 160:\t\t * per-speed rules, the netdev trigger rejects that combination.\n 161:\t\t * on_set holds every speed this LED can indicate and is what\n 162:\t\t * mtk_phy_led_hw_ctrl_set() programs for TRIGGER_NETDEV_LINK, so\n 163:\t\t * report the speed independent rule only when they are all on.\n 164:\t\t */\n 165:\t\tif ((on \u0026 on_set) == on_set) {\n 166:\t\t\t*rules |= BIT(TRIGGER_NETDEV_LINK);\n 167:\t\t} else {\n 168:\t\t\tif (on \u0026 MTK_PHY_LED_ON_LINK10)\n 169:\t\t\t\t*rules |= BIT(TRIGGER_NETDEV_LINK_10);\n 170:\t\n 171:\t\t\tif (on \u0026 MTK_PHY_LED_ON_LINK100)\n 172:\t\t\t\t*rules |= BIT(TRIGGER_NETDEV_LINK_100);\n 173:\t\n 174:\t\t\tif (on \u0026 MTK_PHY_LED_ON_LINK1000)\n 175:\t\t\t\t*rules |= BIT(TRIGGER_NETDEV_LINK_1000);\n 176:\t\n 177:\t\t\tif (on \u0026 MTK_PHY_LED_ON_LINK2500)\n 178:\t\t\t\t*rules |= BIT(TRIGGER_NETDEV_LINK_2500);\n 179:\t\t}\n 180:\t\n 181:\t\tif (on \u0026 MTK_PHY_LED_ON_FDX)\n 182:\t\t\t*rules |= BIT(TRIGGER_NETDEV_FULL_DUPLEX);\n 183:\t\n 184:\t\tif (on \u0026 MTK_PHY_LED_ON_HDX)\n 185:\t\t\t*rules |= BIT(TRIGGER_NETDEV_HALF_DUPLEX);\n 186:\t\n 187:\t\tif (blink \u0026 rx_blink_set)\n 188:\t\t\t*rules |= BIT(TRIGGER_NETDEV_RX);\n 189:\t\n 190:\t\tif (blink \u0026 tx_blink_set)\n 191:\t\t\t*rules |= BIT(TRIGGER_NETDEV_TX);\n 192:\t\n 193:\t\treturn 0;\n 194:\t}\n 195:\tEXPORT_SYMBOL_GPL(mtk_phy_led_hw_ctrl_get);\n 196:\t\n 197:\tint mtk_phy_led_hw_ctrl_set(struct phy_device *phydev, u8 index,\n"
} |
| 43/2 | 2026/09/12 13:56 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 46356 output: 27 thoughts: 570 Thoughts: **My Analysis of the `mtk_phy_leds_state_init` Issue**
Okay, here's what I'm seeing. I was just staring at this `mtk_phy_leds_state_init` function, and it's immediately clear that the `rules` pointer is NULL when it's first called. That's a huge red flag! The code jumps out immediately. It's skipping right over the logic because of that `if (!rules) return 0;` at the beginning. Basically, the routine returns before line 159 even gets a chance.
So, I started digging. The only other place `rules` could possibly have a non-NULL value is if the `phydev->drv->led_hw_control_get(phydev, phyled->index, rules);` function is called. Where is that called from? It turns out that this call only occurs from `phy_led_hw_control_get` in `drivers/net/phy/phy_device.c`.
Now, here's where it gets interesting. `phy_led_hw_control_get` is registered as `cdev->hw_control_get` only under very specific conditions, thanks to the `of_phy_led` function. Basically, this can only happen if all those checks in the conditional are true:
```c
#ifdef CONFIG_LEDS_TRIGGERS
if (phydev->drv->led_hw_is_supported &&
phydev->drv->led_hw_control_set &&
phydev->drv->led_hw_control_get) {
cdev->hw_control_is_supported = phy_led_hw_is_supported;
cdev->hw_control_set = phy_led_hw_control_set;
cdev->hw_control_get = phy_led_hw_control_get;
cdev->hw_control_trigger = "netdev";
}
cdev->hw_control_get_device = phy_led_hw_control_get_device;
#endif
```
And `of_phy_led` itself is only called if `leds = of_get_child_by_name(dev->of_node, "leds");` returns something, which requires a `dev->of_node` -- a Device Tree (DT) or Open Firmware device node!
Hold on a second. Does this system even use Device Tree? My experience is that x86/amd64 platforms typically use ACPI, not DT. Unless it's a test environment using a mock DT or an OF overlay, this doesn't apply to a standard QEMU x86/amd64 kernel. MDIO PHY LEDs on x86 typically won't use DT.
I was considering if this could be an emulated USB device or something, but the `udev->dev.of_node` will be NULL on those unless someone used device-tree to describe them (which is ARM / embedded based).
Can device tree overlays or fake DT nodes even be loaded via configfs or sysfs or something? That's a definite possibility. It's time to check the kernel configuration to see if `CONFIG_OF` and `CONFIG_OF_OVERLAY` are enabled on amd64. That would explain the issue.
|
| 44/2 | 2026/09/12 13:56 | tool | grepper |
0mArgs:{
"Expression": "config OF\\b",
"PathPrefix": "drivers/of"
}Results: {
"Output": "drivers/of/Kconfig=8=config BUILTIN_DTB_ALL\n--\ndrivers/of/Kconfig-10-\ndrivers/of/Kconfig:11:menuconfig OF\ndrivers/of/Kconfig-12-\tbool \"Device Tree and Open Firmware support\"\n"
} |
| 45/2 | 2026/09/12 13:56 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 47768 output: 37 thoughts: 520 Thoughts: **Diving Deep into MediaTek PHY Drivers** Okay, hold on a second. Before I go any further, I need to get a grip on the *specific* hardware these PHY drivers are even designed for. Let's dig into the `drivers/net/phy/mediatek/Kconfig` file. Aha! There are two main MediaTek PHY configurations: `MEDIATEK_2P5GE_PHY` and `MEDIATEK_GE_SOC_PHY`. The first, the `2P5GE_PHY` is dependent on `(ARM64 && ARCH_MEDIATEK) || COMPILE_TEST`. The second, the `GE_SOC_PHY`, is dependent on `(ARM64 && ARCH_MEDIATEK) || ECONET || COMPILE_TEST`. Looking at these dependencies, the pieces are falling into place: these are MediaTek SoC built-in Gigabit and 2.5GbE Ethernet PHYs! This confirms my suspicion that we're talking about SoCs like the MT7981, MT7988, EN7528, AN7581, and AN7583 – the Wi-Fi router and gateway SoCs, like the Filogic 820/880/Econet platforms. These PHYs are *integrated* into the MediaTek SoCs. Now, specifically, the MT7988 2.5GbE PHY is interesting. It requires `ioremap` on `MT7988_2P5GE_PMB_FW_BASE`, which is a physical memory-mapped address (0x0f100000), along with a firmware request via `request_firmware_direct` for `"mediatek/mt7988/i2p5ge-phy-pmb.bin"`. This firmware interaction is key. And then, there's the GE PHYs' calibration to consider. Time to go deeper and look at `mt798x_phy_calibration(phydev)` in `mtk-ge-soc.c`. |
| 46/2 | 2026/09/12 13:56 | tool | grepper |
0mArgs:{
"Expression": "mt798x_phy_calibration",
"PathPrefix": "drivers/net/phy/mediatek"
}Results: {
"Output": "drivers/net/phy/mediatek/mtk-ge-soc.c=1138=static int start_cal(struct phy_device *phydev, enum CAL_ITEM cal_item,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1163-\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1164:static int mt798x_phy_calibration(struct phy_device *phydev)\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1165-{\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c=1210=static int mt798x_phy_config_init(struct phy_device *phydev)\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1223-\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1224:\treturn mt798x_phy_calibration(phydev);\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1225-}\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c=1373=static int mt7988_phy_probe(struct phy_device *phydev)\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1410-\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1411:\treturn mt798x_phy_calibration(phydev);\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1412-}\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c=1414=static int mt7981_phy_probe(struct phy_device *phydev)\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1426-\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1427:\treturn mt798x_phy_calibration(phydev);\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1428-}\n"
} |
| 47/2 | 2026/09/12 13:56 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 49334 output: 46 thoughts: 15 Thoughts: Okay, let's dive into this `mt7988_phy_probe`. Here's what I'm thinking: **Analyzing the `mt7988_phy_probe` Function** Alright, I'm looking at this probe function for the MT7988 PHY. My initial thought is to quickly establish what this thing is *supposed* to do. It's a "probe" function, meaning it's the entry point when the driver is attempting to attach to a hardware instance. So, the first things that jump out are the expectations around device matching and resource acquisition. I need to understand what this function does with the `struct platform_device *pdev` passed to it. Is it using the standard platform device API? Does it look at the device tree properties? What are the key resource types it's looking for? Memory regions, interrupts, clock signals – those are the usual suspects. I'll be looking for common patterns: registering PHY operations, configuring the hardware, potentially initializing internal data structures. Are there any early PHY reset or power-up sequences? I'll need to see how the driver interacts with the hardware, probably through some kind of register access abstraction. I'll need to know whether the initialization sequence includes any PHY-specific settings or calibrations that are critical for performance or compatibility. What's the error handling like? How does it deal with potential failures during hardware initialization? Does it handle device tree properties? That will be key to understanding the full scope of how this driver is being implemented. I'm going to quickly skim to get a high-level sense of what resources the driver has access to, and look for any interesting hints regarding the PHY type. This is probably going to be the gateway for future analysis. Let's dig in. |
| 48/2 | 2026/09/12 13:56 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/mediatek/mtk-ge-soc.c",
"FirstLine": 1373,
"LineCount": 40
}Results: {
"Contents": "1373:\tstatic int mt7988_phy_probe(struct phy_device *phydev)\n1374:\t{\n1375:\t\tstruct mtk_socphy_shared *shared;\n1376:\t\tstruct mtk_socphy_priv *priv;\n1377:\t\tint err;\n1378:\t\n1379:\t\tif (phydev-\u003emdio.addr \u003e 3)\n1380:\t\t\treturn -EINVAL;\n1381:\t\n1382:\t\terr = devm_phy_package_join(\u0026phydev-\u003emdio.dev, phydev, 0,\n1383:\t\t\t\t\t sizeof(struct mtk_socphy_shared));\n1384:\t\tif (err)\n1385:\t\t\treturn err;\n1386:\t\n1387:\t\tif (phy_package_probe_once(phydev)) {\n1388:\t\t\terr = mt7988_phy_probe_shared(phydev);\n1389:\t\t\tif (err)\n1390:\t\t\t\treturn err;\n1391:\t\t}\n1392:\t\n1393:\t\tshared = phy_package_get_priv(phydev);\n1394:\t\tpriv = \u0026shared-\u003epriv[phydev-\u003emdio.addr];\n1395:\t\n1396:\t\tphydev-\u003epriv = priv;\n1397:\t\n1398:\t\tmtk_phy_leds_state_init(phydev);\n1399:\t\n1400:\t\terr = mt7988_phy_fix_leds_polarities(phydev);\n1401:\t\tif (err)\n1402:\t\t\treturn err;\n1403:\t\n1404:\t\t/* Disable TX power saving at probing to:\n1405:\t\t * 1. Meet common mode compliance test criteria\n1406:\t\t * 2. Make sure that TX-VCM calibration works fine\n1407:\t\t */\n1408:\t\tphy_modify_mmd(phydev, MDIO_MMD_VEND1, MTK_PHY_RXADC_CTRL_RG7,\n1409:\t\t\t MTK_PHY_DA_AD_BUF_BIAS_LP_MASK, 0x3 \u003c\u003c 8);\n1410:\t\n1411:\t\treturn mt798x_phy_calibration(phydev);\n1412:\t}\n"
} |
| 49/2 | 2026/09/12 13:56 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 50399 output: 46 thoughts: 82 Thoughts: **Diving into the MT7988 PHY Probe** Okay, let's dissect this `mt7988_phy_probe` function. My initial focus is on the interplay between `devm_phy_package_join` and `mt7988_phy_probe_shared`. That's where the real magic happens, I suspect. The question then is, what does `mt7988_phy_probe_shared` *actually* do? Time to dive into the code. Let's head over to lines 1320 through 1372 in `mtk-ge-soc.c`. That should give us the details we need. |
| 50/2 | 2026/09/12 13:57 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/mediatek/mtk-ge-soc.c",
"FirstLine": 1320,
"LineCount": 55
}Results: {
"Contents": "1320:\t\t\t\t mt7988_phy_led_get_polarity(phydev, index) ?\n1321:\t\t\t\t\tMTK_PHY_LED_ON_POLARITY : 0);\n1322:\t\n1323:\t\t/* Only now setup pinctrl to avoid bogus blinking */\n1324:\t\tpinctrl = devm_pinctrl_get_select(\u0026phydev-\u003emdio.dev, \"gbe-led\");\n1325:\t\tif (IS_ERR(pinctrl))\n1326:\t\t\tdev_err(\u0026phydev-\u003emdio.bus-\u003edev,\n1327:\t\t\t\t\"Failed to setup PHY LED pinctrl\\n\");\n1328:\t\n1329:\t\treturn 0;\n1330:\t}\n1331:\t\n1332:\tstatic int mt7988_phy_probe_shared(struct phy_device *phydev)\n1333:\t{\n1334:\t\tstruct device_node *np = dev_of_node(\u0026phydev-\u003emdio.bus-\u003edev);\n1335:\t\tstruct mtk_socphy_shared *shared = phy_package_get_priv(phydev);\n1336:\t\tstruct device_node *pio_np;\n1337:\t\tstruct regmap *regmap;\n1338:\t\tu32 reg;\n1339:\t\tint ret;\n1340:\t\n1341:\t\t/* The LED0 of the 4 PHYs in MT7988 are wired to SoC pins LED_A, LED_B,\n1342:\t\t * LED_C and LED_D respectively. At the same time those pins are used to\n1343:\t\t * bootstrap configuration of the reference clock source (LED_A),\n1344:\t\t * DRAM DDRx16b x2/x1 (LED_B) and boot device (LED_C, LED_D).\n1345:\t\t * In practice this is done using a LED and a resistor pulling the pin\n1346:\t\t * either to GND or to VIO.\n1347:\t\t * The detected value at boot time is accessible at run-time using the\n1348:\t\t * TPBANK0 register located in the gpio base of the pinctrl, in order\n1349:\t\t * to read it here it needs to be referenced by a phandle called\n1350:\t\t * 'mediatek,pio' in the MDIO bus hosting the PHY.\n1351:\t\t * The 4 bits in TPBANK0 are kept as package shared data and are used to\n1352:\t\t * set LED polarity for each of the LED0.\n1353:\t\t */\n1354:\t\tpio_np = of_parse_phandle(np, \"mediatek,pio\", 0);\n1355:\t\tif (!pio_np)\n1356:\t\t\treturn -ENODEV;\n1357:\t\n1358:\t\tregmap = device_node_to_regmap(pio_np);\n1359:\t\tof_node_put(pio_np);\n1360:\t\n1361:\t\tif (IS_ERR(regmap))\n1362:\t\t\treturn PTR_ERR(regmap);\n1363:\t\n1364:\t\tret = regmap_read(regmap, RG_GPIO_MISC_TPBANK0, \u0026reg);\n1365:\t\tif (ret)\n1366:\t\t\treturn ret;\n1367:\t\n1368:\t\tshared-\u003eboottrap = FIELD_GET(RG_GPIO_MISC_TPBANK0_BOOTMODE, reg);\n1369:\t\n1370:\t\treturn 0;\n1371:\t}\n1372:\t\n1373:\tstatic int mt7988_phy_probe(struct phy_device *phydev)\n1374:\t{\n"
} |
| 51/2 | 2026/09/12 13:57 | llm | patch-evaluator |
1mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 51656 output: 46 thoughts: 3035 Thoughts: **Analyzing Reachability of Network PHY LED Control Code in the Linux Kernel** Okay, I need to figure out if the code I'm looking at, specifically related to MediaTek PHY LED control, is actually reachable and testable in a standard fuzzing environment. The presence of Device Tree (`DT`) is immediately a key concern. I see functions like `of_parse_phandle` and `device_node_to_regmap` being used, which screams DT dependency. But then I remember some PHY probe functions, such as `mt7981_phy_probe` and `an7581_phy_probe`. Aha! Looking at `an7581_phy_probe`, it seems the driver *might* work without DT, given the pinctrl setup and allocation. But then, it does `phydev->priv = priv;`, so it's not fatal if `pinctrl` fails. The real question is how the `led_hw_control_get` function pointer gets populated. I trace the call path: `phydev->drv->led_hw_control_get` gets called via `phy_led_hw_control_get`. But, where is `phy_led_hw_control_get` assigned? It is assigned in `of_phy_led()`, which, in turn, is only called by `of_phy_leds()`. And guess what? `of_phy_leds()` *explicitly* checks for a device tree node (`phydev->mdio.dev.of_node`) and a "leds" child node. If either of those are missing, `of_phy_leds` just returns 0, and *nothing* happens! No LED class device is registered for the PHY! This is where I hit a major roadblock: on amd64 (my target architecture in this case), there is *no* PHY device tree node. It seems to require a specific DT structure with a "leds" child, which is specific to MediaTek SoCs. Even on ARM64, this setup is still DT-dependent. Could I somehow *create* a fake DT node or use an overlay on amd64? I check the `Kconfig` for Device Tree and see that standard configurations do not automatically enable features like `OF_OVERLAY`, though the base DT support (`OF`) seems to be available in the kernel. The question is: does a standard amd64 kernel in syzkaller have OF enabled? I recall the core triage philosophy in syzkaller which states that code is only fuzzable if it's reachable in standard virtualized environments. The key point is: *structurally unreachable hardware* is explicitly excluded (e.g. ASIC or PCIe cards not emulated in QEMU), as well as code paths exclusive to other architectures. Analyzing `mtk-phy-lib.c`, the modified code depends on `rules` being not-NULL. If `rules == NULL`, the new code is *never* executed, because there's an early return. The code only executes if `rules` is non-NULL. But, when is `mtk_phy_led_hw_ctrl_get` called with `rules != NULL`? I trace all callers, and it seems that `mtk_phy_led_hw_ctrl_get` is called from `mt798x_2p5ge_phy_led_hw_control_get` and `mt798x_phy_led_hw_control_get`, *both* of these functions being called only via `phydev->drv->led_hw_control_get`, and nowhere else. I then check every call of `phydev->drv->led_hw_control_get` in the whole kernel, and discover the only call sites are `mtk_phy_leds_state_init()` where `rules` is NULL, and `phy_led_hw_control_get` which calls our target function. The function `phy_led_hw_control_get` is also called through `struct led_classdev`. Where does `phy_led_hw_control_get` get assigned to `cdev->hw_control_get`? Only in `of_phy_led()`. `of_phy_led()` is called *only* by `of_phy_leds()` which is *only* called by `phy_probe()`. Again, we are back at Device Tree dependency: `of_phy_leds()` will only be called if a valid device tree node with the "leds" child exists! Now, does the hardware itself even get probed in QEMU? `mt798x_2p5 |
| 52/2 | 2026/09/12 13:58 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/mediatek/mtk-ge-soc.c",
"FirstLine": 1160,
"LineCount": 50
}Results: {
"Contents": "1160:\t\n1161:\t\treturn 0;\n1162:\t}\n1163:\t\n1164:\tstatic int mt798x_phy_calibration(struct phy_device *phydev)\n1165:\t{\n1166:\t\tstruct nvmem_cell *cell;\n1167:\t\tint ret = 0;\n1168:\t\tsize_t len;\n1169:\t\tu32 *buf;\n1170:\t\n1171:\t\tcell = nvmem_cell_get(\u0026phydev-\u003emdio.dev, \"phy-cal-data\");\n1172:\t\tif (IS_ERR(cell)) {\n1173:\t\t\tif (PTR_ERR(cell) == -EPROBE_DEFER)\n1174:\t\t\t\treturn PTR_ERR(cell);\n1175:\t\t\treturn 0;\n1176:\t\t}\n1177:\t\n1178:\t\tbuf = (u32 *)nvmem_cell_read(cell, \u0026len);\n1179:\t\tnvmem_cell_put(cell);\n1180:\t\tif (IS_ERR(buf))\n1181:\t\t\treturn PTR_ERR(buf);\n1182:\t\n1183:\t\tif (!buf[0] || !buf[1] || !buf[2] || !buf[3] || len \u003c 4 * sizeof(u32)) {\n1184:\t\t\tphydev_err(phydev, \"invalid efuse data\\n\");\n1185:\t\t\tret = -EINVAL;\n1186:\t\t\tgoto out;\n1187:\t\t}\n1188:\t\n1189:\t\tret = start_cal(phydev, REXT, EFUSE_M, NO_PAIR, NO_PAIR, buf);\n1190:\t\tif (ret)\n1191:\t\t\tgoto out;\n1192:\t\tret = start_cal(phydev, TX_OFFSET, EFUSE_M, NO_PAIR, NO_PAIR, buf);\n1193:\t\tif (ret)\n1194:\t\t\tgoto out;\n1195:\t\tret = start_cal(phydev, TX_AMP, EFUSE_M, NO_PAIR, NO_PAIR, buf);\n1196:\t\tif (ret)\n1197:\t\t\tgoto out;\n1198:\t\tret = start_cal(phydev, TX_R50, EFUSE_M, PAIR_A, PAIR_D, buf);\n1199:\t\tif (ret)\n1200:\t\t\tgoto out;\n1201:\t\tret = start_cal(phydev, TX_VCM, SW_M, PAIR_A, PAIR_A, buf);\n1202:\t\tif (ret)\n1203:\t\t\tgoto out;\n1204:\t\n1205:\tout:\n1206:\t\tkfree(buf);\n1207:\t\treturn ret;\n1208:\t}\n1209:\t\n"
} |
| 53/2 | 2026/09/12 13:58 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 56535 output: 29 thoughts: 1097 Thoughts: **Analyzing the LED Control Flow in Mediatek PHY Drivers on amd64**
Okay, so even if `mt7981_phy_probe` succeeds, I'm thinking about the control flow for PHY LEDs. Could `of_phy_leds` *ever* actually run? I have a hunch it won't. `of_phy_leds` hinges on the presence of a "leds" child node under `phydev->mdio.dev.of_node`. But wait...on amd64, is a Device Tree even compiled or used? My target architecture is amd64! I recall that on amd64, we rely on ACPI to describe the platform hardware, not Device Tree. So, the kernel doesn't boot with a DT on amd64.
Even with `CONFIG_OF` compiled in as a test, `of_root` would be NULL. That immediately kills any chance of `of_phy_leds` executing on amd64. That means `phydev->mdio.dev.of_node` will *never* be set.
Let's consider a scenario where an MDIO bus does exist, maybe from a USB network dongle like an asix. Even then, when the USB device registers the MDIO bus and scans addresses 0-31, the USB net driver *still* doesn't populate `dev.of_node` because there's no OF tree on amd64. That means `phydev->mdio.dev.of_node` remains NULL.
Now, when `phy_probe` runs and calls `of_phy_leds(phydev)`, it first checks:
```c
static int of_phy_leds(struct phy_device *phydev)
{
struct device_node *node = phydev->mdio.dev.of_node;
struct device_node *leds, *led;
int err;
if (!node)
return 0;
```
It returns *immediately*! No LED devices are ever created for the PHY in that case. And, since there's no LED class device, `cdev->hw_control_get` is never registered. And since it's never registered, `phy_led_hw_control_get()` is NEVER called. Therefore, `phydev->drv->led_hw_control_get()` is NEVER called with `rules != NULL`.
So, in the case of `rules == NULL` (in `mtk_phy_leds_state_init`), `mtk_phy_led_hw_ctrl_get()` ends up with:
```c
if (!rules)
return 0;
```
which returns 0 before the changed code!
Wait a second. Could `mtk_phy_led_hw_ctrl_get` be called from *anywhere else*? Let's check. I need to go through every single reference to `mtk_phy_led_hw_ctrl_get` in the *entire* codebase.
I found:
1. Definition in `drivers/net/phy/mediatek/mtk-phy-lib.c`.
2. Header declaration in `drivers/net/phy/mediatek/mtk.h`.
3. Call in `drivers/net/phy/mediatek/mtk-2p5ge.c`: `mt798x_2p5ge_phy_led_hw_control_get`.
4. Call in `drivers/net/phy/mediatek/mtk-ge-soc.c`: `mt798x_phy_led_hw_control_get`.
That's it! Only *two* callers in the whole kernel! And both of those are the `led_hw_control_get` callbacks for the phy_driver. Now, *who* calls `drv->led_hw_control_get`? Only two places in the entire kernel:
1. `mtk_phy_leds_state_init()` in `drivers/net/phy/mediatek/mtk-phy-lib.c` (and that passes rules = NULL).
2. `phy_led_hw_control_get()` in `drivers/net/phy/phy_device.c`.
But remember, `phy_led_hw_control_get()` is *only* hooked to `led_cdev->hw_control_get` inside `of_phy_led()`! And `of_phy_led()` is only called from `of_phy_leds()` if `phydev->mdio.dev.of_node` has a "
|
| 54/2 | 2026/09/12 13:58 | tool | grepper |
0mArgs:{
"Expression": "hw_control_get\\b",
"PathPrefix": "drivers/"
}Results: {
"Output": "\nFull output is too long, showing 500 out of 646 lines.\nUse more precise expression if possible.\n\ndrivers/leds/trigger/ledtrig-netdev.c=173=static bool supports_hw_control(struct led_classdev *led_cdev)\ndrivers/leds/trigger/ledtrig-netdev.c-174-{\ndrivers/leds/trigger/ledtrig-netdev.c:175:\tif (!led_cdev-\u003ehw_control_get || !led_cdev-\u003ehw_control_set ||\ndrivers/leds/trigger/ledtrig-netdev.c-176-\t !led_cdev-\u003ehw_control_is_supported)\n--\ndrivers/leds/trigger/ledtrig-netdev.c=736=static int netdev_trig_activate(struct led_classdev *led_cdev)\n--\ndrivers/leds/trigger/ledtrig-netdev.c-772-\ndrivers/leds/trigger/ledtrig-netdev.c:773:\t\t\trc = led_cdev-\u003ehw_control_get(led_cdev, \u0026mode);\ndrivers/leds/trigger/ledtrig-netdev.c-774-\t\t\tif (!rc)\n--\ndrivers/net/dsa/mv88e6xxx/leds.c=632=static int\ndrivers/net/dsa/mv88e6xxx/leds.c:633:mv88e6xxx_led_hw_control_get(struct mv88e6xxx_port *p, int led, unsigned long *rules)\ndrivers/net/dsa/mv88e6xxx/leds.c-634-{\n--\ndrivers/net/dsa/mv88e6xxx/leds.c=701=static int\ndrivers/net/dsa/mv88e6xxx/leds.c:702:mv88e6xxx_led0_hw_control_get(struct led_classdev *ldev, unsigned long *rules)\ndrivers/net/dsa/mv88e6xxx/leds.c-703-{\n--\ndrivers/net/dsa/mv88e6xxx/leds.c-705-\ndrivers/net/dsa/mv88e6xxx/leds.c:706:\treturn mv88e6xxx_led_hw_control_get(p, 0, rules);\ndrivers/net/dsa/mv88e6xxx/leds.c-707-}\n--\ndrivers/net/dsa/mv88e6xxx/leds.c=709=static int\ndrivers/net/dsa/mv88e6xxx/leds.c:710:mv88e6xxx_led1_hw_control_get(struct led_classdev *ldev, unsigned long *rules)\ndrivers/net/dsa/mv88e6xxx/leds.c-711-{\n--\ndrivers/net/dsa/mv88e6xxx/leds.c-713-\ndrivers/net/dsa/mv88e6xxx/leds.c:714:\treturn mv88e6xxx_led_hw_control_get(p, 1, rules);\ndrivers/net/dsa/mv88e6xxx/leds.c-715-}\n--\ndrivers/net/dsa/mv88e6xxx/leds.c=745=int mv88e6xxx_port_setup_leds(struct mv88e6xxx_chip *chip, int port)\n--\ndrivers/net/dsa/mv88e6xxx/leds.c-809-\t\t\tl-\u003ehw_control_set = mv88e6xxx_led0_hw_control_set;\ndrivers/net/dsa/mv88e6xxx/leds.c:810:\t\t\tl-\u003ehw_control_get = mv88e6xxx_led0_hw_control_get;\ndrivers/net/dsa/mv88e6xxx/leds.c-811-\t\t\tl-\u003ehw_control_get_device = mv88e6xxx_led0_hw_control_get_device;\n--\ndrivers/net/dsa/mv88e6xxx/leds.c-816-\t\t\tl-\u003ehw_control_set = mv88e6xxx_led1_hw_control_set;\ndrivers/net/dsa/mv88e6xxx/leds.c:817:\t\t\tl-\u003ehw_control_get = mv88e6xxx_led1_hw_control_get;\ndrivers/net/dsa/mv88e6xxx/leds.c-818-\t\t\tl-\u003ehw_control_get_device = mv88e6xxx_led1_hw_control_get_device;\n--\ndrivers/net/dsa/qca/qca8k-leds.c=309=static int\ndrivers/net/dsa/qca/qca8k-leds.c:310:qca8k_cled_hw_control_get(struct led_classdev *ldev, unsigned long *rules)\ndrivers/net/dsa/qca/qca8k-leds.c-311-{\n--\ndrivers/net/dsa/qca/qca8k-leds.c=365=qca8k_parse_port_leds(struct qca8k_priv *priv, struct fwnode_handle *port, int port_num)\n--\ndrivers/net/dsa/qca/qca8k-leds.c-424-\t\tport_led-\u003ecdev.hw_control_set = qca8k_cled_hw_control_set;\ndrivers/net/dsa/qca/qca8k-leds.c:425:\t\tport_led-\u003ecdev.hw_control_get = qca8k_cled_hw_control_get;\ndrivers/net/dsa/qca/qca8k-leds.c-426-\t\tport_led-\u003ecdev.hw_control_get_device = qca8k_cled_hw_control_get_device;\n--\ndrivers/net/ethernet/intel/igc/igc_leds.c=162=static int igc_led_hw_control_set(struct led_classdev *led_cdev,\n--\ndrivers/net/ethernet/intel/igc/igc_leds.c-193-\ndrivers/net/ethernet/intel/igc/igc_leds.c:194:static int igc_led_hw_control_get(struct led_classdev *led_cdev,\ndrivers/net/ethernet/intel/igc/igc_leds.c-195-\t\t\t\t unsigned long *flags)\n--\ndrivers/net/ethernet/intel/igc/igc_leds.c=239=static int igc_setup_ldev(struct igc_led_classdev *ldev,\n--\ndrivers/net/ethernet/intel/igc/igc_leds.c-256-\tled_cdev-\u003ehw_control_set = igc_led_hw_control_set;\ndrivers/net/ethernet/intel/igc/igc_leds.c:257:\tled_cdev-\u003ehw_control_get = igc_led_hw_control_get;\ndrivers/net/ethernet/intel/igc/igc_leds.c-258-\tled_cdev-\u003ehw_control_get_device = igc_led_hw_control_get_device;\n--\ndrivers/net/ethernet/realtek/r8169_leds.c=70=static int rtl8168_led_hw_control_set(struct led_classdev *led_cdev,\n--\ndrivers/net/ethernet/realtek/r8169_leds.c-89-\ndrivers/net/ethernet/realtek/r8169_leds.c:90:static int rtl8168_led_hw_control_get(struct led_classdev *led_cdev,\ndrivers/net/ethernet/realtek/r8169_leds.c-91-\t\t\t\t unsigned long *flags)\n--\ndrivers/net/ethernet/realtek/r8169_leds.c=130=static void rtl8168_setup_ldev(struct r8169_led_classdev *ldev,\n--\ndrivers/net/ethernet/realtek/r8169_leds.c-144-\tled_cdev-\u003ehw_control_set = rtl8168_led_hw_control_set;\ndrivers/net/ethernet/realtek/r8169_leds.c:145:\tled_cdev-\u003ehw_control_get = rtl8168_led_hw_control_get;\ndrivers/net/ethernet/realtek/r8169_leds.c-146-\tled_cdev-\u003ehw_control_get_device = r8169_led_hw_control_get_device;\n--\ndrivers/net/ethernet/realtek/r8169_leds.c=182=static int rtl8125_led_hw_control_set(struct led_classdev *led_cdev,\n--\ndrivers/net/ethernet/realtek/r8169_leds.c-202-\ndrivers/net/ethernet/realtek/r8169_leds.c:203:static int rtl8125_led_hw_control_get(struct led_classdev *led_cdev,\ndrivers/net/ethernet/realtek/r8169_leds.c-204-\t\t\t\t unsigned long *flags)\n--\ndrivers/net/ethernet/realtek/r8169_leds.c=228=static void rtl8125_setup_led_ldev(struct r8169_led_classdev *ldev,\n--\ndrivers/net/ethernet/realtek/r8169_leds.c-242-\tled_cdev-\u003ehw_control_set = rtl8125_led_hw_control_set;\ndrivers/net/ethernet/realtek/r8169_leds.c:243:\tled_cdev-\u003ehw_control_get = rtl8125_led_hw_control_get;\ndrivers/net/ethernet/realtek/r8169_leds.c-244-\tled_cdev-\u003ehw_control_get_device = r8169_led_hw_control_get_device;\n--\ndrivers/net/phy/air_an8801.c=333=static int an8801r_led_brightness_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/air_an8801.c-356-\ndrivers/net/phy/air_an8801.c:357:static int an8801r_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/air_an8801.c-358-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/air_an8801.c=1122=static struct phy_driver airoha_driver[] = {\n--\ndrivers/net/phy/air_an8801.c-1142-\t.led_hw_control_set\t= an8801r_led_hw_control_set,\ndrivers/net/phy/air_an8801.c:1143:\t.led_hw_control_get\t= an8801r_led_hw_control_get,\ndrivers/net/phy/air_an8801.c-1144-\t.led_polarity_set\t= an8801r_led_polarity_set,\n--\ndrivers/net/phy/air_en8811h.c=670=static int air_led_brightness_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/air_en8811h.c-694-\ndrivers/net/phy/air_en8811h.c:695:static int air_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/air_en8811h.c-696-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/air_en8811h.c=1512=static struct phy_driver en8811h_driver[] = {\n--\ndrivers/net/phy/air_en8811h.c-1531-\t.led_hw_control_set\t= air_led_hw_control_set,\ndrivers/net/phy/air_en8811h.c:1532:\t.led_hw_control_get\t= air_led_hw_control_get,\ndrivers/net/phy/air_en8811h.c-1533-},\n--\ndrivers/net/phy/air_en8811h.c-1553-\t.led_hw_control_set\t= air_led_hw_control_set,\ndrivers/net/phy/air_en8811h.c:1554:\t.led_hw_control_get\t= air_led_hw_control_get,\ndrivers/net/phy/air_en8811h.c-1555-} };\n--\ndrivers/net/phy/aquantia/aquantia.h=248=int aqr_phy_led_hw_is_supported(struct phy_device *phydev, u8 index,\ndrivers/net/phy/aquantia/aquantia.h-249-\t\t\t\tunsigned long rules);\ndrivers/net/phy/aquantia/aquantia.h:250:int aqr_phy_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/aquantia/aquantia.h-251-\t\t\t unsigned long *rules);\n--\ndrivers/net/phy/aquantia/aquantia_leds.c=34=int aqr_phy_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/aquantia/aquantia_leds.c-46-\ndrivers/net/phy/aquantia/aquantia_leds.c:47:int aqr_phy_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/aquantia/aquantia_leds.c-48-\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/aquantia/aquantia_main.c=1181=static struct phy_driver aqr_driver[] = {\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1239-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1240:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1241-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1266-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1267:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1268-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1293-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1294:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1295-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1320-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1321:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1322-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1356-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1357:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1358-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1424-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1425:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1426-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1450-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1451:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1452-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1477-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1478:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1479-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1504-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1505:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1506-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1531-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1532:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1533-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/aquantia/aquantia_main.c-1557-\t.led_hw_control_set = aqr_phy_led_hw_control_set,\ndrivers/net/phy/aquantia/aquantia_main.c:1558:\t.led_hw_control_get = aqr_phy_led_hw_control_get,\ndrivers/net/phy/aquantia/aquantia_main.c-1559-\t.led_polarity_set = aqr_phy_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c=788=static int as21xxx_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/as21xxx.c-802-\ndrivers/net/phy/as21xxx.c:803:static int as21xxx_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/as21xxx.c-804-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/as21xxx.c=946=static struct phy_driver as21xxx_drivers[] = {\n--\ndrivers/net/phy/as21xxx.c-965-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:966:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-967-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-977-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:978:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-979-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-989-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:990:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-991-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1001-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1002:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1003-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1013-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1014:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1015-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1025-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1026:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1027-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1037-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1038:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1039-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1049-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1050:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1051-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1061-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1062:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1063-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/as21xxx.c-1073-\t\t.led_hw_control_set = as21xxx_led_hw_control_set,\ndrivers/net/phy/as21xxx.c:1074:\t\t.led_hw_control_get = as21xxx_led_hw_control_get,\ndrivers/net/phy/as21xxx.c-1075-\t\t.led_polarity_set = as21xxx_led_polarity_set,\n--\ndrivers/net/phy/bcm84881.c=158=static int bcm8489x_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/bcm84881.c-183-\ndrivers/net/phy/bcm84881.c:184:static int bcm8489x_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/bcm84881.c-185-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/bcm84881.c=419=static struct phy_driver bcm84881_drivers[] = {\n--\ndrivers/net/phy/bcm84881.c-443-\t\t.led_hw_control_set = bcm8489x_led_hw_control_set,\ndrivers/net/phy/bcm84881.c:444:\t\t.led_hw_control_get = bcm8489x_led_hw_control_get,\ndrivers/net/phy/bcm84881.c-445-\t}, {\n--\ndrivers/net/phy/bcm84881.c-457-\t\t.led_hw_control_set = bcm8489x_led_hw_control_set,\ndrivers/net/phy/bcm84881.c:458:\t\t.led_hw_control_get = bcm8489x_led_hw_control_get,\ndrivers/net/phy/bcm84881.c-459-\t},\n--\ndrivers/net/phy/dp83822.c=1097=static int dp83822_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/dp83822.c-1123-\ndrivers/net/phy/dp83822.c:1124:static int dp83822_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/dp83822.c-1125-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/dp83822.c-1199-\t\t.led_hw_control_set = dp83822_led_hw_control_set,\t\\\ndrivers/net/phy/dp83822.c:1200:\t\t.led_hw_control_get = dp83822_led_hw_control_get,\t\\\ndrivers/net/phy/dp83822.c-1201-\t\t.attach_mdi_port = dp83822_attach_mdi_port\t\t\\\n--\ndrivers/net/phy/dp83867.c=1069=static int dp83867_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/dp83867.c-1085-\ndrivers/net/phy/dp83867.c:1086:static int dp83867_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/dp83867.c-1087-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/dp83867.c=1183=static struct phy_driver dp83867_driver[] = {\n--\ndrivers/net/phy/dp83867.c-1214-\t\t.led_hw_control_set = dp83867_led_hw_control_set,\ndrivers/net/phy/dp83867.c:1215:\t\t.led_hw_control_get = dp83867_led_hw_control_get,\ndrivers/net/phy/dp83867.c-1216-\t\t.led_polarity_set = dp83867_led_polarity_set,\n--\ndrivers/net/phy/dp83td510.c=367=static int dp83td510_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/dp83td510.c-385-\ndrivers/net/phy/dp83td510.c:386:static int dp83td510_led_hw_control_get(struct phy_device *phydev,\ndrivers/net/phy/dp83td510.c-387-\t\t\t\t\tu8 index, unsigned long *rules)\n--\ndrivers/net/phy/dp83td510.c=939=static struct phy_driver dp83td510_driver[] = {\n--\ndrivers/net/phy/dp83td510.c-963-\t.led_hw_control_set = dp83td510_led_hw_control_set,\ndrivers/net/phy/dp83td510.c:964:\t.led_hw_control_get = dp83td510_led_hw_control_get,\ndrivers/net/phy/dp83td510.c-965-\t.led_polarity_set = dp83td510_led_polarity_set,\n--\ndrivers/net/phy/intel-xway.c=428=static int xway_gphy_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/intel-xway.c-450-\ndrivers/net/phy/intel-xway.c:451:static int xway_gphy_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/intel-xway.c-452-\t\t\t\t\tunsigned long *rules)\n--\ndrivers/net/phy/intel-xway.c=584=static struct phy_driver xway_gphy[] = {\n--\ndrivers/net/phy/intel-xway.c-598-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:599:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-600-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-617-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:618:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-619-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-636-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:637:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-638-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-655-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:656:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-657-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-673-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:674:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-675-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-691-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:692:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-693-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-709-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:710:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-711-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-727-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:728:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-729-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-745-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:746:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-747-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/intel-xway.c-763-\t\t.led_hw_is_supported = xway_gphy_led_hw_is_supported,\ndrivers/net/phy/intel-xway.c:764:\t\t.led_hw_control_get = xway_gphy_led_hw_control_get,\ndrivers/net/phy/intel-xway.c-765-\t\t.led_hw_control_set = xway_gphy_led_hw_control_set,\n--\ndrivers/net/phy/marvell-88q2xxx.c=1040=static int mv88q2xxx_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/marvell-88q2xxx.c-1062-\ndrivers/net/phy/marvell-88q2xxx.c:1063:static int mv88q2xxx_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/marvell-88q2xxx.c-1064-\t\t\t\t\tunsigned long *rules)\n--\ndrivers/net/phy/marvell-88q2xxx.c=1102=static struct phy_driver mv88q2xxx_driver[] = {\n--\ndrivers/net/phy/marvell-88q2xxx.c-1139-\t\t.led_hw_control_set\t= mv88q2xxx_led_hw_control_set,\ndrivers/net/phy/marvell-88q2xxx.c:1140:\t\t.led_hw_control_get\t= mv88q2xxx_led_hw_control_get,\ndrivers/net/phy/marvell-88q2xxx.c-1141-\t},\n--\ndrivers/net/phy/marvell.c=3541=static int m88e1318_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/marvell.c-3569-\ndrivers/net/phy/marvell.c:3570:static int m88e1318_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/marvell.c-3571-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/marvell.c=3667=static struct phy_driver marvell_drivers[] = {\n--\ndrivers/net/phy/marvell.c-3834-\t\t.led_hw_control_set = m88e1318_led_hw_control_set,\ndrivers/net/phy/marvell.c:3835:\t\t.led_hw_control_get = m88e1318_led_hw_control_get,\ndrivers/net/phy/marvell.c-3836-\t},\n--\ndrivers/net/phy/marvell.c-3948-\t\t.led_hw_control_set = m88e1318_led_hw_control_set,\ndrivers/net/phy/marvell.c:3949:\t\t.led_hw_control_get = m88e1318_led_hw_control_get,\ndrivers/net/phy/marvell.c-3950-\t\t.attach_mii_port = m88e1510_attach_mii_port,\n--\ndrivers/net/phy/marvell.c-3980-\t\t.led_hw_control_set = m88e1318_led_hw_control_set,\ndrivers/net/phy/marvell.c:3981:\t\t.led_hw_control_get = m88e1318_led_hw_control_get,\ndrivers/net/phy/marvell.c-3982-\t},\n--\ndrivers/net/phy/marvell.c-4011-\t\t.led_hw_control_set = m88e1318_led_hw_control_set,\ndrivers/net/phy/marvell.c:4012:\t\t.led_hw_control_get = m88e1318_led_hw_control_get,\ndrivers/net/phy/marvell.c-4013-\t},\n--\ndrivers/net/phy/marvell.c-4172-\t\t.led_hw_control_set = m88e1318_led_hw_control_set,\ndrivers/net/phy/marvell.c:4173:\t\t.led_hw_control_get = m88e1318_led_hw_control_get,\ndrivers/net/phy/marvell.c-4174-\t},\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c=298=static int mt798x_2p5ge_phy_led_hw_is_supported(struct phy_device *phydev,\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c-304-\ndrivers/net/phy/mediatek/mtk-2p5ge.c:305:static int mt798x_2p5ge_phy_led_hw_control_get(struct phy_device *phydev,\ndrivers/net/phy/mediatek/mtk-2p5ge.c-306-\t\t\t\t\t u8 index, unsigned long *rules)\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c=379=static struct phy_driver mtk_2p5gephy_driver[] = {\n--\ndrivers/net/phy/mediatek/mtk-2p5ge.c-395-\t\t.led_hw_is_supported = mt798x_2p5ge_phy_led_hw_is_supported,\ndrivers/net/phy/mediatek/mtk-2p5ge.c:396:\t\t.led_hw_control_get = mt798x_2p5ge_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-2p5ge.c-397-\t\t.led_hw_control_set = mt798x_2p5ge_phy_led_hw_control_set,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c=1269=static int mt798x_phy_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1275-\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1276:static int mt798x_phy_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1277-\t\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c=1495=static struct phy_driver mtk_socphy_driver[] = {\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1510-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1511:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1512-\t},\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1527-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1528:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1529-\t},\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1538-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1539:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1540-\t\t.led_polarity_set = an7581_phy_led_polarity_set,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1551-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1552:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1553-\t\t.led_polarity_set = an7581_phy_led_polarity_set,\n--\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1563-\t\t.led_hw_control_set = mt798x_phy_led_hw_control_set,\ndrivers/net/phy/mediatek/mtk-ge-soc.c:1564:\t\t.led_hw_control_get = mt798x_phy_led_hw_control_get,\ndrivers/net/phy/mediatek/mtk-ge-soc.c-1565-\t\t.led_polarity_set = an7581_phy_led_polarity_set,\n--\ndrivers/net/phy/mediatek/mtk-phy-lib.c=342=void mtk_phy_leds_state_init(struct phy_device *phydev)\n--\ndrivers/net/phy/mediatek/mtk-phy-lib.c-346-\tfor (i = 0; i \u003c 2; ++i)\ndrivers/net/phy/mediatek/mtk-phy-lib.c:347:\t\tphydev-\u003edrv-\u003eled_hw_control_get(phydev, i, NULL);\ndrivers/net/phy/mediatek/mtk-phy-lib.c-348-}\n--\ndrivers/net/phy/motorcomm.c=1752=static int yt8521_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/motorcomm.c-1793-\ndrivers/net/phy/motorcomm.c:1794:static int yt8521_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/motorcomm.c-1795-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/motorcomm.c=3075=static struct phy_driver motorcomm_phy_drvs[] = {\n--\ndrivers/net/phy/motorcomm.c-3102-\t\t.led_hw_control_set = yt8521_led_hw_control_set,\ndrivers/net/phy/motorcomm.c:3103:\t\t.led_hw_control_get = yt8521_led_hw_control_get,\ndrivers/net/phy/motorcomm.c-3104-\t},\n--\ndrivers/net/phy/motorcomm.c-3124-\t\t.led_hw_control_set = yt8521_led_hw_control_set,\ndrivers/net/phy/motorcomm.c:3125:\t\t.led_hw_control_get = yt8521_led_hw_control_get,\ndrivers/net/phy/motorcomm.c-3126-\t},\n--\ndrivers/net/phy/mscc/mscc_main.c=2330=static int vsc85xx_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/mscc/mscc_main.c-2349-\ndrivers/net/phy/mscc/mscc_main.c:2350:static int vsc85xx_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mscc/mscc_main.c-2351-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/mscc/mscc_main.c=2548=static struct phy_driver vsc85xx_driver[] = {\n--\ndrivers/net/phy/mscc/mscc_main.c-2573-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2574:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2575-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2601-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2602:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2603-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2632-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2633:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2634-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2661-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2662:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2663-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2689-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2690:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2691-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2717-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2718:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2719-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2745-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2746:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2747-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2773-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2774:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2775-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2803-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2804:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2805-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2830-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2831:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2832-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2862-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2863:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2864-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2894-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2895:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2896-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2923-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2924:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2925-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2952-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2953:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2954-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mscc/mscc_main.c-2982-\t.led_hw_is_supported = vsc85xx_led_hw_is_supported,\ndrivers/net/phy/mscc/mscc_main.c:2983:\t.led_hw_control_get = vsc85xx_led_hw_control_get,\ndrivers/net/phy/mscc/mscc_main.c-2984-\t.led_hw_control_set = vsc85xx_led_hw_control_set,\n--\ndrivers/net/phy/mxl-86110.c=438=static int mxl86110_led_hw_is_supported(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/mxl-86110.c-450-\ndrivers/net/phy/mxl-86110.c:451:static int mxl86110_led_hw_control_get(struct phy_device *phydev, u8 index,\ndrivers/net/phy/mxl-86110.c-452-\t\t\t\t unsigned long *rules)\n--\ndrivers/net/phy/mxl-86110.c=606=static int mxl86110_broadcast_cfg(struct phy_device *phydev)\n--\ndrivers/net/phy/mxl-86110.c-629- * /sys/class/leds interface; the functions led_hw_is_supported,\ndrivers/net/phy/mxl-86110.c:630: * led_hw_control_get, and led_hw_control_set are used\ndrivers/net/phy/mxl-86110.c-631- * to support this mechanism.\n--\n\n"
} |
| 55/2 | 2026/09/12 13:58 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 73705 output: 199 thoughts: 1193 Thoughts: **Analysis of Patch Reachability** Okay, let's break this down. My initial thought is to trace the execution path of the modified code in `mtk_phy_led_hw_ctrl_get()`. The code is called via `led_cdev->hw_control_get` within `ledtrig-netdev.c`, specifically when the `led_cdev` is a PHY LED configured through `of_phy_led()`. `of_phy_led()` requires a Device Tree node with a "leds" child under the PHY device. That much is clear. Now, considering the hardware context: this `mtk-phy-lib` is employed by drivers like `mtk-2p5ge.c` and `mtk-ge-soc.c`, which are specifically for MediaTek's integrated Ethernet PHYs found in SoCs such as MT7981, MT7988, EN7528, and AN7581. These are embedded ARM64/Econet platforms, not something you'd find on a standard amd64 system or in a QEMU environment. These need SoC-specific pin controllers, memory-mapped registers, and Device Tree descriptions (e.g., `gbe-led`, `i2p5gbe-led` pinctrl, `mediatek,pio` phandles, and firmware like `mediatek/mt7988/i2p5ge-phy-pmb.bin`). On our target architecture, amd64, these drivers (`MEDIATEK_2P5GE_PHY` and `MEDIATEK_GE_SOC_PHY`) can *only* be compiled if `COMPILE_TEST` is enabled. Even *if* they're compiled, the underlying hardware isn't present, and QEMU doesn't emulate these MediaTek PHYs. Even if I were to somehow spoof a PHY ID through a USB Ethernet dongle, the probe will fail due to firmware loading, pinctrl issues, or missing Device Tree nodes. Thus, `of_phy_leds` will never be invoked, and consequently, `rules` will never be passed to `mtk_phy_led_hw_ctrl_get()`. Since the patch *only* modifies the `if (rules)` code path, the modified code is completely unreachable. This aligns perfectly with Section 2 of the guidelines – "Structurally unreachable hardware" – specifically, vendor-specific silicon (MediaTek's PHYs here) requiring hardware not emulated by standard QEMU. It also falls under "Unreachable execution paths" because this code is exclusively tied to an architecture (ARM64) other than our target (amd64). I'm confident this isn't worth fuzzing. Syzkaller on amd64 in QEMU is utterly incapable of instantiating the MediaTek PHY device, let alone its Device Tree-based LED triggers. Therefore, the parameters are clear: `WorthFuzzing: false`, with a reasoning that precisely details the MediaTek SoC hardware dependence, Device Tree requirements, and structural unreachability on amd64 in a standard environment. No `EnableConfigs` or `FocusSymbols` are relevant here. I'm ready to `set-results`. |
| 56/2 | 2026/09/12 13:59 | tool | set-results |
0mArgs:{
"EnableConfigs": [],
"FocusSymbols": [],
"Reasoning": "The patch modifies mtk_phy_led_hw_ctrl_get() in drivers/net/phy/mediatek/mtk-phy-lib.c, which is used exclusively by MediaTek SoC Ethernet PHY drivers (mtk-2p5ge and mtk-ge-soc). On the target architecture (amd64), these drivers depend on COMPILE_TEST and cannot be executed because they require MediaTek ARM64 SoC hardware (MT7981, MT7988, EN7528) not emulated in standard QEMU. Furthermore, the modified logic specifically executes when reading hardware LED rules, which requires DeviceTree child nodes ('leds') to register the PHY LED class device. Consequently, the modified code is structurally unreachable in standard virtualized fuzzing environments.",
"WorthFuzzing": false
}Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"Reasoning": "The patch modifies mtk_phy_led_hw_ctrl_get() in drivers/net/phy/mediatek/mtk-phy-lib.c, which is used exclusively by MediaTek SoC Ethernet PHY drivers (mtk-2p5ge and mtk-ge-soc). On the target architecture (amd64), these drivers depend on COMPILE_TEST and cannot be executed because they require MediaTek ARM64 SoC hardware (MT7981, MT7988, EN7528) not emulated in standard QEMU. Furthermore, the modified logic specifically executes when reading hardware LED rules, which requires DeviceTree child nodes ('leds') to register the PHY LED class device. Consequently, the modified code is structurally unreachable in standard virtualized fuzzing environments.",
"WorthFuzzing": false
} |
| 57/1 | 2026/09/12 13:59 | action | If |
0mArgs:{
"WorthFuzzing": false
}Results: null |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|