| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/08/06 16:21 | flow | patch-triage |
7mArgs:null Results: {
"EnableConfigs": [
"REALTEK_PHY"
],
"FocusSymbols": [
"rtlgen_write_mmd",
"rtl822x_write_mmd"
],
"Reasoning": "The patch fixes a bug where arguments were swapped in a call to rtlgen_write_vend2 inside rtlgen_write_mmd. This function is a .write_mmd callback for Realtek PHY drivers and is reachable from userspace via SIOCSMIIREG ioctl or ETHTOOL_SEEE when a Realtek PHY is attached.",
"WorthFuzzing": true
} |
| 1/1 | 2026/08/06 16:21 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit 31a803c0fd6fdfd1c7fcbf6c1fda9867651a2efc\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Thu Aug 6 16:21:18 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c\nindex a0a79192384ee..177b62a7b2d16 100644\n--- a/drivers/net/phy/realtek/realtek_main.c\n+++ b/drivers/net/phy/realtek/realtek_main.c\n@@ -1768,7 +1768,7 @@ static int rtlgen_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,\n \tif (devnum == MDIO_MMD_VEND2)\n \t\tret = rtlgen_write_vend2(phydev, regnum, val);\n \telse if (devnum == MDIO_MMD_AN \u0026\u0026 regnum == MDIO_AN_EEE_ADV)\n-\t\tret = rtlgen_write_vend2(phydev, regnum, RTL_MDIO_AN_EEE_ADV);\n+\t\tret = rtlgen_write_vend2(phydev, RTL_MDIO_AN_EEE_ADV, val);\n \telse\n \t\tret = -EOPNOTSUPP;\n \n"
} |
| 2/1 | 2026/08/06 16:21 | agent | patch-evaluator |
7mModel:best-expensive Args: null Results: {
"EnableConfigs": [
"REALTEK_PHY"
],
"FocusSymbols": [
"rtlgen_write_mmd",
"rtl822x_write_mmd"
],
"Reasoning": "The patch fixes a bug where arguments were swapped in a call to rtlgen_write_vend2 inside rtlgen_write_mmd. This function is a .write_mmd callback for Realtek PHY drivers and is reachable from userspace via SIOCSMIIREG ioctl or ETHTOOL_SEEE when a Realtek PHY is attached.",
"WorthFuzzing": true
}Instruction: You are an expert Linux kernel maintainer. Your job is to review a provided patch series and determine if it makes functional changes to the kernel that should be fuzzed. IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively use your code access tools to examine the actual source code and confirm any assumptions. Return WorthFuzzing=false if the patch only contains: - Modifications to Documentation/, Kconfig files, or code comments. - Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints. - Changes to numeric constants or macros that do not functionally alter execution flow. - Code paths that are impossible to reach in virtualized environments like GCE or QEMU, even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim). - Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed, ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU. - Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove) that are executed only during PCI hot-unplug or sysfs driver unbind operations. If it modifies reachable core kernel logic, drivers, or architectures, use your code search tools to verify the code can be executed, then return WorthFuzzing=true. When returning WorthFuzzing=true, you MUST ALSO: 1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols. Avoid listing generic hot-path functions to prevent skewed test distributions. Prefer non-static, non-inlined API entrypoint functions over internal static helper functions (which are inlined by the compiler and do not have distinct symbol addresses). 2. Identify any specific CONFIG_ options required to properly test this new/modified feature. Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions. Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed for Kbuild to compile the code statically into vmlinux. List them in the EnableConfigs output array, and DO NOT add a '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: For your convenience, here is the diff of the changes:
commit 31a803c0fd6fdfd1c7fcbf6c1fda9867651a2efc
Author: syz-cluster <triage@syzkaller.com>
Date: Thu Aug 6 16:21:18 2026 +0000
syz-cluster: applied patch under review
diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index a0a79192384ee..177b62a7b2d16 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -1768,7 +1768,7 @@ static int rtlgen_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,
if (devnum == MDIO_MMD_VEND2)
ret = rtlgen_write_vend2(phydev, regnum, val);
else if (devnum == MDIO_MMD_AN && regnum == MDIO_AN_EEE_ADV)
- ret = rtlgen_write_vend2(phydev, regnum, RTL_MDIO_AN_EEE_ADV);
+ ret = rtlgen_write_vend2(phydev, RTL_MDIO_AN_EEE_ADV, val);
else
ret = -EOPNOTSUPP;
|
| 3/2 | 2026/08/06 16:21 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 2143 output: 42 thoughts: 233 Thoughts: **Analyzing a Realtek PHY Driver Patch** Okay, so I've got this patch here that's touching `drivers/net/phy/realtek/realtek_main.c`. It's a Realtek PHY driver, which is a common area for potential issues. The description indicates a bugfix in `rtlgen_write_mmd`, specifically related to how `rtlgen_write_vend2` is being called. Right, the original code had the arguments for `rtlgen_write_vend2` swapped. It looks like it was passing `regnum` and `val` in the wrong order. The fixed code seems to correct this to `rtlgen_write_vend2(phydev, RTL_MDIO_AN_EEE_ADV, val)`. Now, the important question is: can this be triggered? I need to think about reachability. Since it's a PHY driver, it's pretty likely that we can hit this code path somehow. Virtual network devices that use PHYs are a good starting point, and I'd bet the MDIO bus is the key here. We might be able to instantiate PHYs using the MDIO bus to trigger this, or via MDIO ioctls. Let's see...syzkaller! It's likely that syzkaller can handle this, right? It can fuzz MDIO buses and PHYs using `vhci` or something similar, or just through direct MDIO ioctl manipulation. That should be a very effective way to get to this code. Okay, let's dive into `rtlgen_write_mmd` and see what the function does. |
| 4/2 | 2026/08/06 16:21 | tool | grepper |
0mArgs:{
"Expression": "rtlgen_write_mmd",
"PathPrefix": "drivers/net/phy/realtek/realtek_main.c"
}Results: {
"Output": "drivers/net/phy/realtek/realtek_main.c=1745=static int rtlgen_read_mmd(struct phy_device *phydev, int devnum, u16 regnum)\n--\ndrivers/net/phy/realtek/realtek_main.c-1762-\ndrivers/net/phy/realtek/realtek_main.c:1763:static int rtlgen_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,\ndrivers/net/phy/realtek/realtek_main.c-1764-\t\t\t u16 val)\n--\ndrivers/net/phy/realtek/realtek_main.c=1795=static int rtl822x_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,\n--\ndrivers/net/phy/realtek/realtek_main.c-1797-{\ndrivers/net/phy/realtek/realtek_main.c:1798:\tint ret = rtlgen_write_mmd(phydev, devnum, regnum, val);\ndrivers/net/phy/realtek/realtek_main.c-1799-\n--\ndrivers/net/phy/realtek/realtek_main.c=3086=static struct phy_driver realtek_drvs[] = {\n--\ndrivers/net/phy/realtek/realtek_main.c-3203-\t\t.read_mmd\t= rtlgen_read_mmd,\ndrivers/net/phy/realtek/realtek_main.c:3204:\t\t.write_mmd\t= rtlgen_write_mmd,\ndrivers/net/phy/realtek/realtek_main.c-3205-\t}, {\n"
} |
| 5/2 | 2026/08/06 16:21 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 3217 output: 35 thoughts: 44 Thoughts: Okay, let's see what we're dealing with. **Investigating rtlgen_write_mmd in Realtek PHY Drivers** Right, so `rtlgen_write_mmd` is being employed as the `.write_mmd` function pointer within a handful of PHY drivers residing in the `realtek_drvs` directory. My immediate thought is, let's nail down what the configuration requirements are for this specific function. I need to understand the dependencies and the overall context to ensure this is used as intended. Time to dig into the associated files, I need to understand its role. |
| 6/2 | 2026/08/06 16:21 | tool | grepper |
0mArgs:{
"Expression": "realtek_main.o",
"PathPrefix": "drivers/net/phy/realtek/"
}Results: {
"Output": "drivers/net/phy/realtek/Makefile-1-# SPDX-License-Identifier: GPL-2.0\ndrivers/net/phy/realtek/Makefile:2:realtek-y\t\t\t+= realtek_main.o\ndrivers/net/phy/realtek/Makefile-3-realtek-$(CONFIG_REALTEK_PHY_HWMON) += realtek_hwmon.o\n"
} |
| 7/2 | 2026/08/06 16:21 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 3525 output: 29 thoughts: 18 Thoughts: Here's my thought process, as if I were considering this: **Investigating the Realtek PHY Driver Location** Okay, so I need to figure out where the Realtek PHY drivers are located within the kernel source tree. My first instinct, and the standard practice for this kind of investigation, is to check the `Makefile` within the relevant driver directory. Specifically, I'm thinking about the network PHY drivers. Given my experience, `drivers/net/phy/` is the logical place to start. A quick peek in `drivers/net/phy/Makefile` will probably give me the answer, listing the specific object files or source files associated with Realtek PHY support. This should be a pretty straightforward way to pinpoint the relevant code. |
| 8/2 | 2026/08/06 16:21 | tool | grepper |
0mArgs:{
"Expression": "realtek",
"PathPrefix": "drivers/net/phy/Makefile"
}Results: {
"Output": "drivers/net/phy/Makefile=95=obj-$(CONFIG_QSEMI_PHY)\t\t+= qsemi.o\ndrivers/net/phy/Makefile:96:obj-$(CONFIG_REALTEK_PHY)\t+= realtek/\ndrivers/net/phy/Makefile-97-obj-$(CONFIG_RENESAS_PHY)\t+= uPD60620.o\n"
} |
| 9/2 | 2026/08/06 16:21 | llm | patch-evaluator |
1mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 3830 output: 32 thoughts: 31 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: **Investigating the Realtek PHY Configuration** Right, so we need `CONFIG_REALTEK_PHY`. That's the starting point. Now, before I just blindly enable it, let's be smart about this. The critical question is: what are its dependencies? There's always a web of interconnected configurations in these things, and overlooking a dependency can lead to hours of debugging later on. Let's dig in and figure out the prerequisites for `CONFIG_REALTEK_PHY`. We don't want to break anything else in the process, and we want to ensure everything needed is enabled or set up correctly before we move forward. |
| 10/2 | 2026/08/06 16:22 | tool | grepper |
0mArgs:{
"Expression": "config REALTEK_PHY",
"PathPrefix": "drivers/net/phy/"
}Results: {
"Output": "drivers/net/phy/realtek/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/net/phy/realtek/Kconfig:2:config REALTEK_PHY\ndrivers/net/phy/realtek/Kconfig-3-\ttristate \"Realtek PHYs\"\n--\ndrivers/net/phy/realtek/Kconfig=8=if REALTEK_PHY\ndrivers/net/phy/realtek/Kconfig-9-\ndrivers/net/phy/realtek/Kconfig:10:config REALTEK_PHY_HWMON\ndrivers/net/phy/realtek/Kconfig-11-\tbool \"HWMON support for Realtek PHYs\"\n"
} |
| 11/2 | 2026/08/06 16:22 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 4229 output: 37 thoughts: 20 Thoughts: Okay, here's the summary, rendered as if I'm the one thinking it: **Digging into the Realtek PHY Kconfig** Right, let's get down to brass tacks. I need to understand the dependencies for this Realtek PHY driver. My first instinct, as always, is to dive right into the `drivers/net/phy/realtek/Kconfig` file. That's the heart of the matter for configuration options, and knowing its dependencies will give me the context I need. This file will reveal what other components or settings are required or can impact this specific PHY driver's inclusion. I'll be looking for things like: necessary core network features, specific hardware support, other Realtek dependencies, or perhaps even broader architectural requirements. The Kconfig file is my key to unlocking the configuration puzzle and understanding how this driver fits into the broader kernel ecosystem. |
| 12/2 | 2026/08/06 16:22 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/realtek/Kconfig",
"FirstLine": 1,
"LineCount": 20
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0-only\n 2:\tconfig REALTEK_PHY\n 3:\t\ttristate \"Realtek PHYs\"\n 4:\t\tselect PHY_PACKAGE\n 5:\t\thelp\n 6:\t\t Currently supports RTL821x/RTL822x and fast ethernet PHYs\n 7:\t\n 8:\tif REALTEK_PHY\n 9:\t\n 10:\tconfig REALTEK_PHY_HWMON\n 11:\t\tbool \"HWMON support for Realtek PHYs\"\n 12:\t\tdepends on HWMON \u0026\u0026 !(REALTEK_PHY=y \u0026\u0026 HWMON=m)\n 13:\t\thelp\n 14:\t\t Optional hwmon support for the temperature sensor\n 15:\t\n 16:\tendif # REALTEK_PHY\n"
} |
| 13/2 | 2026/08/06 16:22 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 4692 output: 29 thoughts: 37 Thoughts: **Navigating the PHY Configuration Dependencies** Okay, so this configuration option isn't directly tied to anything *obvious* in the code. However, the fact that it resides within `drivers/net/phy/Kconfig` is a pretty strong hint. That directory suggests we're dealing with PHY (Physical Layer) drivers, so let's check its dependencies... and there it is: `PHYLIB`. It's a key dependency. Now I need to see what PHYLIB enables, and if that gives more clarity. |
| 14/2 | 2026/08/06 16:22 | tool | grepper |
0mArgs:{
"Expression": "config PHYLIB",
"PathPrefix": "drivers/net/phy/"
}Results: {
"Output": "drivers/net/phy/Kconfig=6=config PHYLINK\n--\ndrivers/net/phy/Kconfig-14-\ndrivers/net/phy/Kconfig:15:menuconfig PHYLIB\ndrivers/net/phy/Kconfig-16-\ttristate \"PHY Device support and infrastructure\"\n--\ndrivers/net/phy/Kconfig=46=config OPEN_ALLIANCE_HELPERS\n--\ndrivers/net/phy/Kconfig-48-\ndrivers/net/phy/Kconfig:49:config PHYLIB_LEDS\ndrivers/net/phy/Kconfig-50-\tdef_bool OF\n"
} |
| 15/2 | 2026/08/06 16:22 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 5030 output: 35 thoughts: 129 Thoughts: **My Analysis of PHYLIB and MDIO Fuzzing Potential** Okay, so I'm thinking about how we can reach `PHYLIB` from user space. It looks like we've got a couple of solid options: netlink or good old-fashioned ioctls, like `SIOCSMIIREG`. That's a good starting point. Now, the real question is how we can integrate this into a fuzzing setup with syzkaller. Can syzkaller fuzz MDIO buses using virtual devices? We could use `tun`, `veth`, or something similar and attach PHYs that way. Or, perhaps, we can target the `mdio` subsystem directly. Wait a minute…I recall seeing MDIO and PHY descriptions in syzkaller already. That's a good sign! It means someone's already put in some groundwork, which is fantastic news. Alright, let's drill down a bit. Let's see if we can reach `rtlgen_write_mmd`. It looks like it's a `.write_mmd` callback. Now, my immediate thought is to trace back and find out where that callback is actually used. Where are the calls to `.write_mmd` happening? That's the key to figuring out the attack surface. |
| 16/2 | 2026/08/06 16:23 | tool | grepper |
0mArgs:{
"Expression": "write_mmd",
"PathPrefix": "drivers/net/phy/phy_device.c"
}Results: {
"Output": "drivers/net/phy/phy_device.c=2786=EXPORT_SYMBOL(genphy_read_mmd_c45);\ndrivers/net/phy/phy_device.c-2787-\ndrivers/net/phy/phy_device.c:2788:int genphy_write_mmd_c45(struct phy_device *phydev, int devnum, u16 regnum,\ndrivers/net/phy/phy_device.c-2789-\t\t\t u16 val)\n--\ndrivers/net/phy/phy_device.c-2795-}\ndrivers/net/phy/phy_device.c:2796:EXPORT_SYMBOL(genphy_write_mmd_c45);\ndrivers/net/phy/phy_device.c-2797-\n--\ndrivers/net/phy/phy_device.c=2806=EXPORT_SYMBOL(genphy_read_mmd_unsupported);\ndrivers/net/phy/phy_device.c-2807-\ndrivers/net/phy/phy_device.c:2808:int genphy_write_mmd_unsupported(struct phy_device *phdev, int devnum,\ndrivers/net/phy/phy_device.c-2809-\t\t\t\t u16 regnum, u16 val)\n--\ndrivers/net/phy/phy_device.c-2812-}\ndrivers/net/phy/phy_device.c:2813:EXPORT_SYMBOL(genphy_write_mmd_unsupported);\ndrivers/net/phy/phy_device.c-2814-\n"
} |
| 17/2 | 2026/08/06 16:23 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 5872 output: 32 thoughts: 14 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience and written in the first person: **API Clarification** Okay, hold on a second. I need to get this straight in my head. I'm focusing on the write path, and I've been mulling over the memory management functions. Then it hit me: the function I'm actually dealing with here, the core API for writing to the memory mapped device (MMD), is `phy_write_mmd`. It's that simple, really. That's the key function to trace and understand; everything else is likely leading to or supporting its execution. Good, that clarifies things. Now I can build on this. |
| 18/2 | 2026/08/06 16:23 | tool | grepper |
0mArgs:{
"Expression": "phy_write_mmd",
"PathPrefix": "drivers/net/phy/"
}Results: {
"Output": "\nFull output is too long, showing 500 out of 1828 lines.\nUse more precise expression if possible.\n\ndrivers/net/phy/adin.c=275=static int adin_config_rgmii_mode(struct phy_device *phydev)\n--\ndrivers/net/phy/adin.c-316-\ndrivers/net/phy/adin.c:317:\treturn phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/adin.c-318-\t\t\t ADIN1300_GE_RGMII_CFG_REG, reg);\n--\ndrivers/net/phy/adin.c=321=static int adin_config_rmii_mode(struct phy_device *phydev)\n--\ndrivers/net/phy/adin.c-343-\ndrivers/net/phy/adin.c:344:\treturn phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/adin.c-345-\t\t\t ADIN1300_GE_RMII_CFG_REG, reg);\n--\ndrivers/net/phy/adin1100.c=192=static int adin_set_powerdown_mode(struct phy_device *phydev, bool en)\n--\ndrivers/net/phy/adin1100.c-195-\ndrivers/net/phy/adin1100.c:196:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/adin1100.c-197-\t\t\t ADIN_CRSM_SFT_PD_CNTRL,\n--\ndrivers/net/phy/adin1140-phy.c=46=static struct phy_driver adin1140_driver[] = {\n--\ndrivers/net/phy/adin1140-phy.c-54-\t\t.read_mmd = genphy_read_mmd_c45,\ndrivers/net/phy/adin1140-phy.c:55:\t\t.write_mmd = genphy_write_mmd_c45,\ndrivers/net/phy/adin1140-phy.c-56-\t\t.get_plca_cfg = genphy_c45_plca_get_cfg,\n--\ndrivers/net/phy/air_an8801.c=272=static int an8801r_led_blink_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/air_an8801.c-300-\t\t\t\t LED_BLINK_DUR_MASK);\ndrivers/net/phy/air_an8801.c:301:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, LED_BLINK_DUR,\ndrivers/net/phy/air_an8801.c-302-\t\t\t\t blink_dur);\n--\ndrivers/net/phy/air_an8801.c-305-\ndrivers/net/phy/air_an8801.c:306:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, LED_ON_DUR,\ndrivers/net/phy/air_an8801.c-307-\t\t\t\t hw_delay_on);\n--\ndrivers/net/phy/air_an8801.c=902=static int an8801r_config_init(struct phy_device *phydev)\n--\ndrivers/net/phy/air_an8801.c-911-\t/* Disable Low Power Mode (LPM) */\ndrivers/net/phy/air_an8801.c:912:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, AN8801_REG_PHY_INTERNAL0,\ndrivers/net/phy/air_an8801.c-913-\t\t\t FIELD_PREP(AN8801_PHY_INTFUNC_MASK, 0x1e));\n--\ndrivers/net/phy/air_an8801.c-916-\ndrivers/net/phy/air_an8801.c:917:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, AN8801_REG_PHY_INTERNAL1,\ndrivers/net/phy/air_an8801.c-918-\t\t\t FIELD_PREP(AN8801_PHY_INTFUNC_MASK, 0x2));\n--\ndrivers/net/phy/air_an8801.c-957-\ndrivers/net/phy/air_an8801.c:958:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/air_an8801.c-959-\t\t\t AN8801_PHY_TX_PAIR_DLY_SEL_GBE,\n--\ndrivers/net/phy/air_an8801.c-964-\ndrivers/net/phy/air_an8801.c:965:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AN8801_PHY_RXADC_CTRL,\ndrivers/net/phy/air_an8801.c-966-\t\t\t AN8801_PHY_RXADC_SAMP_PHSEL_A |\n--\ndrivers/net/phy/air_an8801.c-970-\ndrivers/net/phy/air_an8801.c:971:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AN8801_PHY_RXADC_REV_0,\ndrivers/net/phy/air_an8801.c-972-\t\t\t FIELD_PREP(AN8801_PHY_RXADC_REV_MASK_A, 1));\n--\ndrivers/net/phy/air_an8801.c-975-\ndrivers/net/phy/air_an8801.c:976:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AN8801_PHY_RXADC_REV_1,\ndrivers/net/phy/air_an8801.c-977-\t\t\t FIELD_PREP(AN8801_PHY_RXADC_REV_MASK_C, 1));\n--\ndrivers/net/phy/air_en8811h.c=610=static int air_hw_led_blink_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/air_en8811h.c-628-\tif (changed)\ndrivers/net/phy/air_en8811h.c:629:\t\treturn phy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/air_en8811h.c-630-\t\t\t\t AIR_PHY_LED_BLINK(index),\n--\ndrivers/net/phy/air_en8811h.c=708=static int air_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/air_en8811h.c-764-\ndrivers/net/phy/air_en8811h.c:765:\treturn phy_write_mmd(phydev, MDIO_MMD_VEND2, AIR_PHY_LED_BLINK(index),\ndrivers/net/phy/air_en8811h.c-766-\t\t\t blink);\n--\ndrivers/net/phy/air_en8811h.c=797=static int air_leds_init(struct phy_device *phydev, int num, int dur, int mode)\n--\ndrivers/net/phy/air_en8811h.c-801-\ndrivers/net/phy/air_en8811h.c:802:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, AIR_PHY_LED_DUR_BLINK,\ndrivers/net/phy/air_en8811h.c-803-\t\t\t dur);\n--\ndrivers/net/phy/air_en8811h.c-806-\ndrivers/net/phy/air_en8811h.c:807:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, AIR_PHY_LED_DUR_ON,\ndrivers/net/phy/air_en8811h.c-808-\t\t\t dur \u003e\u003e 1);\n--\ndrivers/net/phy/air_en8811h.c=1281=static int en8811h_config_init(struct phy_device *phydev)\n--\ndrivers/net/phy/air_en8811h.c-1298-\t */\ndrivers/net/phy/air_en8811h.c:1299:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_MCU_CMD_1,\ndrivers/net/phy/air_en8811h.c-1300-\t\t\t AIR_PHY_MCU_CMD_1_MODE1);\n--\ndrivers/net/phy/air_en8811h.c-1302-\t\treturn ret;\ndrivers/net/phy/air_en8811h.c:1303:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_MCU_CMD_2,\ndrivers/net/phy/air_en8811h.c-1304-\t\t\t AIR_PHY_MCU_CMD_2_MODE1);\n--\ndrivers/net/phy/air_en8811h.c-1306-\t\treturn ret;\ndrivers/net/phy/air_en8811h.c:1307:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_MCU_CMD_3,\ndrivers/net/phy/air_en8811h.c-1308-\t\t\t AIR_PHY_MCU_CMD_3_MODE1);\n--\ndrivers/net/phy/air_en8811h.c-1310-\t\treturn ret;\ndrivers/net/phy/air_en8811h.c:1311:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_MCU_CMD_4,\ndrivers/net/phy/air_en8811h.c-1312-\t\t\t AIR_PHY_MCU_CMD_4_MODE1);\n--\ndrivers/net/phy/air_en8811h.c=1452=static int en8811h_clear_intr(struct phy_device *phydev)\n--\ndrivers/net/phy/air_en8811h.c-1455-\ndrivers/net/phy/air_en8811h.c:1456:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_MCU_CMD_3,\ndrivers/net/phy/air_en8811h.c-1457-\t\t\t AIR_PHY_MCU_CMD_3_DOCMD);\n--\ndrivers/net/phy/air_en8811h.c-1460-\ndrivers/net/phy/air_en8811h.c:1461:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_MCU_CMD_4,\ndrivers/net/phy/air_en8811h.c-1462-\t\t\t AIR_PHY_MCU_CMD_4_INTCLR);\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c=90=static int aqr_fw_load_memory(struct phy_device *phydev, u32 addr,\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c-95-\ndrivers/net/phy/aquantia/aquantia_firmware.c:96:\tphy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/aquantia/aquantia_firmware.c-97-\t\t VEND1_GLOBAL_MAILBOX_INTERFACE1,\ndrivers/net/phy/aquantia/aquantia_firmware.c-98-\t\t VEND1_GLOBAL_MAILBOX_INTERFACE1_CRC_RESET);\ndrivers/net/phy/aquantia/aquantia_firmware.c:99:\tphy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/aquantia/aquantia_firmware.c-100-\t\t VEND1_GLOBAL_MAILBOX_INTERFACE3,\ndrivers/net/phy/aquantia/aquantia_firmware.c-101-\t\t VEND1_GLOBAL_MAILBOX_INTERFACE3_MSW_ADDR(addr));\ndrivers/net/phy/aquantia/aquantia_firmware.c:102:\tphy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/aquantia/aquantia_firmware.c-103-\t\t VEND1_GLOBAL_MAILBOX_INTERFACE4,\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c-115-\ndrivers/net/phy/aquantia/aquantia_firmware.c:116:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_MAILBOX_INTERFACE5,\ndrivers/net/phy/aquantia/aquantia_firmware.c-117-\t\t\t VEND1_GLOBAL_MAILBOX_INTERFACE5_MSW_DATA(word));\ndrivers/net/phy/aquantia/aquantia_firmware.c:118:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_MAILBOX_INTERFACE6,\ndrivers/net/phy/aquantia/aquantia_firmware.c-119-\t\t\t VEND1_GLOBAL_MAILBOX_INTERFACE6_LSW_DATA(word));\ndrivers/net/phy/aquantia/aquantia_firmware.c-120-\ndrivers/net/phy/aquantia/aquantia_firmware.c:121:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_MAILBOX_INTERFACE1,\ndrivers/net/phy/aquantia/aquantia_firmware.c-122-\t\t\t VEND1_GLOBAL_MAILBOX_INTERFACE1_EXECUTE |\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c=149=static int aqr_fw_boot(struct phy_device *phydev, const u8 *data, size_t size,\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c-261-\t/* stall the microcprocessor */\ndrivers/net/phy/aquantia/aquantia_firmware.c:262:\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_CONTROL2,\ndrivers/net/phy/aquantia/aquantia_firmware.c-263-\t\t VEND1_GLOBAL_CONTROL2_UP_RUN_STALL | VEND1_GLOBAL_CONTROL2_UP_RUN_STALL_OVD);\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c-283-\t/* Release the microprocessor. UP_RESET must be held for 100 usec. */\ndrivers/net/phy/aquantia/aquantia_firmware.c:284:\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_CONTROL2,\ndrivers/net/phy/aquantia/aquantia_firmware.c-285-\t\t VEND1_GLOBAL_CONTROL2_UP_RUN_STALL |\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c-289-\ndrivers/net/phy/aquantia/aquantia_firmware.c:290:\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_CONTROL2,\ndrivers/net/phy/aquantia/aquantia_firmware.c-291-\t\t VEND1_GLOBAL_CONTROL2_UP_RUN_STALL_OVD);\n--\ndrivers/net/phy/aquantia/aquantia_hwmon.c=55=static int aqr_hwmon_set(struct phy_device *phydev, int reg, long value)\n--\ndrivers/net/phy/aquantia/aquantia_hwmon.c-64-\t/* temp is in s16 range and we're interested in lower 16 bits only */\ndrivers/net/phy/aquantia/aquantia_hwmon.c:65:\treturn phy_write_mmd(phydev, MDIO_MMD_VEND1, reg, (u16)temp);\ndrivers/net/phy/aquantia/aquantia_hwmon.c-66-}\n--\ndrivers/net/phy/aquantia/aquantia_main.c=253=static int aqr_config_intr(struct phy_device *phydev)\n--\ndrivers/net/phy/aquantia/aquantia_main.c-264-\ndrivers/net/phy/aquantia/aquantia_main.c:265:\terr = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_TX_VEND_INT_MASK2,\ndrivers/net/phy/aquantia/aquantia_main.c-266-\t\t\t en ? MDIO_AN_TX_VEND_INT_MASK2_LINK : 0);\n--\ndrivers/net/phy/aquantia/aquantia_main.c-269-\ndrivers/net/phy/aquantia/aquantia_main.c:270:\terr = phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_INT_STD_MASK,\ndrivers/net/phy/aquantia/aquantia_main.c-271-\t\t\t en ? VEND1_GLOBAL_INT_STD_MASK_ALL : 0);\n--\ndrivers/net/phy/aquantia/aquantia_main.c-274-\ndrivers/net/phy/aquantia/aquantia_main.c:275:\terr = phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_INT_VEND_MASK,\ndrivers/net/phy/aquantia/aquantia_main.c-276-\t\t\t en ? VEND1_GLOBAL_INT_VEND_MASK_GLOBAL3 |\n--\ndrivers/net/phy/aquantia/aquantia_main.c=369=static int aqr105_setup_forced(struct phy_device *phydev)\n--\ndrivers/net/phy/aquantia/aquantia_main.c-401-\t}\ndrivers/net/phy/aquantia/aquantia_main.c:402:\tret = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_ADVERTISE, adv);\ndrivers/net/phy/aquantia/aquantia_main.c-403-\tif (ret \u003c 0)\ndrivers/net/phy/aquantia/aquantia_main.c-404-\t\treturn ret;\ndrivers/net/phy/aquantia/aquantia_main.c:405:\tret = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_VEND_PROV, vend);\ndrivers/net/phy/aquantia/aquantia_main.c-406-\tif (ret \u003c 0)\ndrivers/net/phy/aquantia/aquantia_main.c-407-\t\treturn ret;\ndrivers/net/phy/aquantia/aquantia_main.c:408:\tret = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_10GBT_CTRL, ctrl10);\ndrivers/net/phy/aquantia/aquantia_main.c-409-\tif (ret \u003c 0)\n--\ndrivers/net/phy/as21xxx.c=297=static int aeon_firmware_boot(struct phy_device *phydev, const u8 *data,\n--\ndrivers/net/phy/as21xxx.c-307-\ndrivers/net/phy/as21xxx.c:308:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_FW_START_ADDR,\ndrivers/net/phy/as21xxx.c-309-\t\t\t AEON_BOOT_ADDR);\n--\ndrivers/net/phy/as21xxx.c-329-\ndrivers/net/phy/as21xxx.c:330:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/as21xxx.c-331-\t\t\t\t VEND1_GLB_REG_MDIO_INDIRECT_LOAD, val);\n--\ndrivers/net/phy/as21xxx.c-335-\ndrivers/net/phy/as21xxx.c:336:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/as21xxx.c-337-\t\t\t VEND1_GLB_REG_CPU_RESET_ADDR_LO_BASEADDR,\n--\ndrivers/net/phy/as21xxx.c-341-\ndrivers/net/phy/as21xxx.c:342:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/as21xxx.c-343-\t\t\t VEND1_GLB_REG_CPU_RESET_ADDR_HI_BASEADDR,\n--\ndrivers/net/phy/as21xxx.c=405=static int aeon_ipc_send_cmd(struct phy_device *phydev,\n--\ndrivers/net/phy/as21xxx.c-422-\ndrivers/net/phy/as21xxx.c:423:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_IPC_CMD, cmd);\ndrivers/net/phy/as21xxx.c-424-\tif (ret)\n--\ndrivers/net/phy/as21xxx.c=455=static int aeon_ipc_send_msg(struct phy_device *phydev,\n--\ndrivers/net/phy/as21xxx.c-471-\tfor (i = 0; i \u003c data_len / sizeof(u16); i++)\ndrivers/net/phy/as21xxx.c:472:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_IPC_DATA(i),\ndrivers/net/phy/as21xxx.c-473-\t\t\t data[i]);\n--\ndrivers/net/phy/bcm-phy-lib.c=372=int bcm_phy_set_eee(struct phy_device *phydev, bool enable)\n--\ndrivers/net/phy/bcm-phy-lib.c-385-\ndrivers/net/phy/bcm-phy-lib.c:386:\tphy_write_mmd(phydev, MDIO_MMD_AN, BRCM_CL45VEN_EEE_CONTROL, (u32)val);\ndrivers/net/phy/bcm-phy-lib.c-387-\n--\ndrivers/net/phy/bcm-phy-lib.c-404-\ndrivers/net/phy/bcm-phy-lib.c:405:\tphy_write_mmd(phydev, MDIO_MMD_AN, BCM_CL45VEN_EEE_ADV, (u32)val);\ndrivers/net/phy/bcm-phy-lib.c-406-\n--\ndrivers/net/phy/bcm7xxx.c=628=static int bcm7xxx_28nm_ephy_read_mmd(struct phy_device *phydev,\n--\ndrivers/net/phy/bcm7xxx.c-657-\ndrivers/net/phy/bcm7xxx.c:658:static int bcm7xxx_28nm_ephy_write_mmd(struct phy_device *phydev,\ndrivers/net/phy/bcm7xxx.c-659-\t\t\t\t int devnum, u16 regnum, u16 val)\n--\ndrivers/net/phy/bcm7xxx.c=821=static int bcm7xxx_28nm_probe(struct phy_device *phydev)\n--\ndrivers/net/phy/bcm7xxx.c-886-\t.read_mmd\t= bcm7xxx_28nm_ephy_read_mmd,\t\t\t\\\ndrivers/net/phy/bcm7xxx.c:887:\t.write_mmd\t= bcm7xxx_28nm_ephy_write_mmd,\t\t\t\\\ndrivers/net/phy/bcm7xxx.c-888-}\n--\ndrivers/net/phy/bcm84881.c=99=static int bcm8489x_led_write(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/bcm84881.c-103-\ndrivers/net/phy/bcm84881.c:104:\tret = phy_write_mmd(phydev, MDIO_MMD_PMAPMD,\ndrivers/net/phy/bcm84881.c-105-\t\t\t bcm8489x_led_regs[index].mask_low, low);\n--\ndrivers/net/phy/bcm84881.c-107-\t\treturn ret;\ndrivers/net/phy/bcm84881.c:108:\tret = phy_write_mmd(phydev, MDIO_MMD_PMAPMD,\ndrivers/net/phy/bcm84881.c-109-\t\t\t bcm8489x_led_regs[index].mask_ext, ext);\n--\ndrivers/net/phy/bcm87xx.c=34=static int bcm87xx_of_reg_init(struct phy_device *phydev)\n--\ndrivers/net/phy/bcm87xx.c-68-\ndrivers/net/phy/bcm87xx.c:69:\t\tret = phy_write_mmd(phydev, devid, reg, val);\ndrivers/net/phy/bcm87xx.c-70-\t\tif (ret \u003c 0)\n--\ndrivers/net/phy/bcm87xx.c=140=static int bcm87xx_config_intr(struct phy_device *phydev)\n--\ndrivers/net/phy/bcm87xx.c-154-\t\treg |= 1;\ndrivers/net/phy/bcm87xx.c:155:\t\terr = phy_write_mmd(phydev, MDIO_MMD_PCS,\ndrivers/net/phy/bcm87xx.c-156-\t\t\t\t BCM87XX_LASI_CONTROL, reg);\n--\ndrivers/net/phy/bcm87xx.c-158-\t\treg \u0026= ~1;\ndrivers/net/phy/bcm87xx.c:159:\t\terr = phy_write_mmd(phydev, MDIO_MMD_PCS,\ndrivers/net/phy/bcm87xx.c-160-\t\t\t\t BCM87XX_LASI_CONTROL, reg);\n--\ndrivers/net/phy/dp83822.c=214=static int dp83822_config_wol(struct phy_device *phydev,\n--\ndrivers/net/phy/dp83822.c-229-\t\t */\ndrivers/net/phy/dp83822.c:230:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND2, MII_DP83822_WOL_DA1,\ndrivers/net/phy/dp83822.c-231-\t\t\t (mac[1] \u003c\u003c 8) | mac[0]);\ndrivers/net/phy/dp83822.c:232:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND2, MII_DP83822_WOL_DA2,\ndrivers/net/phy/dp83822.c-233-\t\t\t (mac[3] \u003c\u003c 8) | mac[2]);\ndrivers/net/phy/dp83822.c:234:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND2, MII_DP83822_WOL_DA3,\ndrivers/net/phy/dp83822.c-235-\t\t\t (mac[5] \u003c\u003c 8) | mac[4]);\n--\ndrivers/net/phy/dp83822.c-244-\t\tif (wol-\u003ewolopts \u0026 WAKE_MAGICSECURE) {\ndrivers/net/phy/dp83822.c:245:\t\t\tphy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/dp83822.c-246-\t\t\t\t MII_DP83822_RXSOP1,\ndrivers/net/phy/dp83822.c-247-\t\t\t\t (wol-\u003esopass[1] \u003c\u003c 8) | wol-\u003esopass[0]);\ndrivers/net/phy/dp83822.c:248:\t\t\tphy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/dp83822.c-249-\t\t\t\t MII_DP83822_RXSOP2,\ndrivers/net/phy/dp83822.c-250-\t\t\t\t (wol-\u003esopass[3] \u003c\u003c 8) | wol-\u003esopass[2]);\ndrivers/net/phy/dp83822.c:251:\t\t\tphy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/dp83822.c-252-\t\t\t\t MII_DP83822_RXSOP3,\n--\ndrivers/net/phy/dp83822.c-264-\ndrivers/net/phy/dp83822.c:265:\t\treturn phy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/dp83822.c-266-\t\t\t\t MII_DP83822_WOL_CFG, value);\n--\ndrivers/net/phy/dp83822.c=1045=static int dp83822_resume(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83822.c-1052-\ndrivers/net/phy/dp83822.c:1053:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, MII_DP83822_WOL_CFG, value |\ndrivers/net/phy/dp83822.c-1054-\t\t DP83822_WOL_CLR_INDICATION);\n--\ndrivers/net/phy/dp83867.c=211=static int dp83867_set_wol(struct phy_device *phydev,\n--\ndrivers/net/phy/dp83867.c-231-\ndrivers/net/phy/dp83867.c:232:\t\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFPMD1,\ndrivers/net/phy/dp83867.c-233-\t\t\t\t (mac[1] \u003c\u003c 8 | mac[0]));\ndrivers/net/phy/dp83867.c:234:\t\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFPMD2,\ndrivers/net/phy/dp83867.c-235-\t\t\t\t (mac[3] \u003c\u003c 8 | mac[2]));\ndrivers/net/phy/dp83867.c:236:\t\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFPMD3,\ndrivers/net/phy/dp83867.c-237-\t\t\t\t (mac[5] \u003c\u003c 8 | mac[4]));\n--\ndrivers/net/phy/dp83867.c-244-\t\tif (wol-\u003ewolopts \u0026 WAKE_MAGICSECURE) {\ndrivers/net/phy/dp83867.c:245:\t\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFSOP1,\ndrivers/net/phy/dp83867.c-246-\t\t\t\t (wol-\u003esopass[1] \u003c\u003c 8) | wol-\u003esopass[0]);\ndrivers/net/phy/dp83867.c:247:\t\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFSOP2,\ndrivers/net/phy/dp83867.c-248-\t\t\t\t (wol-\u003esopass[3] \u003c\u003c 8) | wol-\u003esopass[2]);\ndrivers/net/phy/dp83867.c:249:\t\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFSOP3,\ndrivers/net/phy/dp83867.c-250-\t\t\t\t (wol-\u003esopass[5] \u003c\u003c 8) | wol-\u003esopass[4]);\n--\ndrivers/net/phy/dp83867.c-270-\ndrivers/net/phy/dp83867.c:271:\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFCFG, val_rxcfg);\ndrivers/net/phy/dp83867.c-272-\tphy_write(phydev, MII_DP83867_MICR, val_micr);\n--\ndrivers/net/phy/dp83867.c=736=static int dp83867_config_init(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83867.c-808-\ndrivers/net/phy/dp83867.c:809:\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIICTL, val);\ndrivers/net/phy/dp83867.c-810-\ndrivers/net/phy/dp83867.c:811:\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIIDCTL,\ndrivers/net/phy/dp83867.c-812-\t\t\t dp83867-\u003erx_id_delay |\n--\ndrivers/net/phy/dp83867.c-816-\t\tval \u0026= ~DP83867_RGMII_EN;\ndrivers/net/phy/dp83867.c:817:\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIICTL, val);\ndrivers/net/phy/dp83867.c-818-\t}\n--\ndrivers/net/phy/dp83867.c-860-\t\t\tval \u0026= ~DP83867_SGMII_TYPE;\ndrivers/net/phy/dp83867.c:861:\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL, val);\ndrivers/net/phy/dp83867.c-862-\n--\ndrivers/net/phy/dp83867.c=935=static int dp83867_phy_reset(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83867.c-953-\t */\ndrivers/net/phy/dp83867.c:954:\terr = phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_DSP_FFE_CFG,\ndrivers/net/phy/dp83867.c-955-\t\t\t 0x0e81);\n--\ndrivers/net/phy/dp83869.c=259=static int dp83869_set_wol(struct phy_device *phydev,\n--\ndrivers/net/phy/dp83869.c-286-\ndrivers/net/phy/dp83869.c:287:\t\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-288-\t\t\t\t\t DP83869_RXFPMD1,\n--\ndrivers/net/phy/dp83869.c-292-\ndrivers/net/phy/dp83869.c:293:\t\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-294-\t\t\t\t\t DP83869_RXFPMD2,\n--\ndrivers/net/phy/dp83869.c-298-\ndrivers/net/phy/dp83869.c:299:\t\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-300-\t\t\t\t\t DP83869_RXFPMD3,\n--\ndrivers/net/phy/dp83869.c-310-\t\tif (wol-\u003ewolopts \u0026 WAKE_MAGICSECURE) {\ndrivers/net/phy/dp83869.c:311:\t\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-312-\t\t\t\t\t DP83869_RXFSOP1,\n--\ndrivers/net/phy/dp83869.c-316-\ndrivers/net/phy/dp83869.c:317:\t\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-318-\t\t\t\t\t DP83869_RXFSOP2,\n--\ndrivers/net/phy/dp83869.c-321-\t\t\t\treturn ret;\ndrivers/net/phy/dp83869.c:322:\t\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-323-\t\t\t\t\t DP83869_RXFSOP3,\n--\ndrivers/net/phy/dp83869.c-346-\ndrivers/net/phy/dp83869.c:347:\tret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RXFCFG, val_rxcfg);\ndrivers/net/phy/dp83869.c-348-\tif (ret)\n--\ndrivers/net/phy/dp83869.c=694=static int dp83869_configure_mode(struct phy_device *phydev,\n--\ndrivers/net/phy/dp83869.c-718-\ndrivers/net/phy/dp83869.c:719:\tret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_OP_MODE,\ndrivers/net/phy/dp83869.c-720-\t\t\t phy_ctrl_val);\n--\ndrivers/net/phy/dp83869.c-753-\ndrivers/net/phy/dp83869.c:754:\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-755-\t\t\t\t DP83869_FX_CTRL, DP83869_FX_CTRL_DEFAULT);\n--\ndrivers/net/phy/dp83869.c-765-\ndrivers/net/phy/dp83869.c:766:\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-767-\t\t\t\t DP83869_FX_CTRL, DP83869_FX_CTRL_DEFAULT);\n--\ndrivers/net/phy/dp83869.c-786-\ndrivers/net/phy/dp83869.c:787:\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-788-\t\t\t\t DP83869_FX_CTRL, DP83869_FX_CTRL_DEFAULT);\n--\ndrivers/net/phy/dp83869.c=804=static int dp83869_config_init(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83869.c-834-\t\t */\ndrivers/net/phy/dp83869.c:835:\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-836-\t\t\t\t DP83869_ANA_PLL_PROG_PI, 0x10);\n--\ndrivers/net/phy/dp83869.c-847-\tif (phy_interface_is_rgmii(phydev)) {\ndrivers/net/phy/dp83869.c:848:\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIIDCTL,\ndrivers/net/phy/dp83869.c-849-\t\t\t\t dp83869-\u003erx_int_delay |\n--\ndrivers/net/phy/dp83869.c-867-\ndrivers/net/phy/dp83869.c:868:\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIICTL,\ndrivers/net/phy/dp83869.c-869-\t\t\t\t val);\n--\ndrivers/net/phy/dp83tc811.c=97=static int dp83811_set_wol(struct phy_device *phydev,\n--\ndrivers/net/phy/dp83tc811.c-112-\t\t */\ndrivers/net/phy/dp83tc811.c:113:\t\tphy_write_mmd(phydev, DP83811_DEVADDR, MII_DP83811_WOL_DA1,\ndrivers/net/phy/dp83tc811.c-114-\t\t\t (mac[1] \u003c\u003c 8) | mac[0]);\ndrivers/net/phy/dp83tc811.c:115:\t\tphy_write_mmd(phydev, DP83811_DEVADDR, MII_DP83811_WOL_DA2,\ndrivers/net/phy/dp83tc811.c-116-\t\t\t (mac[3] \u003c\u003c 8) | mac[2]);\ndrivers/net/phy/dp83tc811.c:117:\t\tphy_write_mmd(phydev, DP83811_DEVADDR, MII_DP83811_WOL_DA3,\ndrivers/net/phy/dp83tc811.c-118-\t\t\t (mac[5] \u003c\u003c 8) | mac[4]);\n--\ndrivers/net/phy/dp83tc811.c-127-\t\tif (wol-\u003ewolopts \u0026 WAKE_MAGICSECURE) {\ndrivers/net/phy/dp83tc811.c:128:\t\t\tphy_write_mmd(phydev, DP83811_DEVADDR,\ndrivers/net/phy/dp83tc811.c-129-\t\t\t\t MII_DP83811_RXSOP1,\ndrivers/net/phy/dp83tc811.c-130-\t\t\t\t (wol-\u003esopass[1] \u003c\u003c 8) | wol-\u003esopass[0]);\ndrivers/net/phy/dp83tc811.c:131:\t\t\tphy_write_mmd(phydev, DP83811_DEVADDR,\ndrivers/net/phy/dp83tc811.c-132-\t\t\t\t MII_DP83811_RXSOP2,\ndrivers/net/phy/dp83tc811.c-133-\t\t\t\t (wol-\u003esopass[3] \u003c\u003c 8) | wol-\u003esopass[2]);\ndrivers/net/phy/dp83tc811.c:134:\t\t\tphy_write_mmd(phydev, DP83811_DEVADDR,\ndrivers/net/phy/dp83tc811.c-135-\t\t\t\t MII_DP83811_RXSOP3,\n--\ndrivers/net/phy/dp83tc811.c-147-\ndrivers/net/phy/dp83tc811.c:148:\t\treturn phy_write_mmd(phydev, DP83811_DEVADDR,\ndrivers/net/phy/dp83tc811.c-149-\t\t\t\t MII_DP83811_WOL_CFG, value);\n--\ndrivers/net/phy/dp83td510.c=530=static int dp83td510_config_intr(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83td510.c-534-\tif (phydev-\u003einterrupts == PHY_INTERRUPT_ENABLED) {\ndrivers/net/phy/dp83td510.c:535:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/dp83td510.c-536-\t\t\t\t DP83TD510E_INTERRUPT_REG_1,\n--\ndrivers/net/phy/dp83td510.c-546-\t} else {\ndrivers/net/phy/dp83td510.c:547:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/dp83td510.c-548-\t\t\t\t DP83TD510E_INTERRUPT_REG_1, 0x0);\n--\ndrivers/net/phy/dp83td510.c=684=static int dp83td510_cable_test_start(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83td510.c-738-\ndrivers/net/phy/dp83td510.c:739:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TD510E_TDR_CFG2,\ndrivers/net/phy/dp83td510.c-740-\t\t\t FIELD_PREP(DP83TD510E_TDR_END_TAP_INDEX_1,\n--\ndrivers/net/phy/dp83td510.c-746-\ndrivers/net/phy/dp83td510.c:747:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TD510E_TDR_FAULT_CFG1,\ndrivers/net/phy/dp83td510.c-748-\t\t\t FIELD_PREP(DP83TD510E_TDR_FLT_LOC_OFFSET_1,\n--\ndrivers/net/phy/dp83td510.c-757-\t */\ndrivers/net/phy/dp83td510.c:758:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TD510E_UNKN_030E,\ndrivers/net/phy/dp83td510.c-759-\t\t\t DP83TD510E_030E_VAL);\n--\ndrivers/net/phy/dp83td510.c-762-\ndrivers/net/phy/dp83td510.c:763:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TD510E_TDR_CFG3,\ndrivers/net/phy/dp83td510.c-764-\t\t\t DP83TD510E_TDR_TX_DURATION_US_DEF);\n--\ndrivers/net/phy/dp83tg720.c=324=static int dp83tg720_cable_test_start(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83tg720.c-340-\ndrivers/net/phy/dp83tg720.c:341:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TG720S_TDR_CFG2,\ndrivers/net/phy/dp83tg720.c-342-\t\t\t 0xa008);\n--\ndrivers/net/phy/dp83tg720.c-345-\ndrivers/net/phy/dp83tg720.c:346:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TG720S_TDR_CFG3,\ndrivers/net/phy/dp83tg720.c-347-\t\t\t 0x0928);\n--\ndrivers/net/phy/dp83tg720.c-350-\ndrivers/net/phy/dp83tg720.c:351:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TG720S_TDR_CFG4,\ndrivers/net/phy/dp83tg720.c-352-\t\t\t 0x0004);\n--\ndrivers/net/phy/dp83tg720.c-355-\ndrivers/net/phy/dp83tg720.c:356:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TG720S_UNKNOWN_0405,\ndrivers/net/phy/dp83tg720.c-357-\t\t\t 0x6400);\n--\ndrivers/net/phy/dp83tg720.c-360-\ndrivers/net/phy/dp83tg720.c:361:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TG720S_UNKNOWN_083F,\ndrivers/net/phy/dp83tg720.c-362-\t\t\t 0x3003);\n--\ndrivers/net/phy/dp83tg720.c=558=static int dp83tg720_config_init(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83tg720.c-575-\t */\ndrivers/net/phy/dp83tg720.c:576:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TG720S_LPS_CFG3,\ndrivers/net/phy/dp83tg720.c-577-\t\t\t DP83TG720S_LPS_CFG3_PWR_MODE_0);\n--\ndrivers/net/phy/intel-xway.c=245=static int xway_gphy_init_leds(struct phy_device *phydev)\n--\ndrivers/net/phy/intel-xway.c-259-\ndrivers/net/phy/intel-xway.c:260:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LEDCH,\ndrivers/net/phy/intel-xway.c-261-\t\t XWAY_MMD_LEDCH_NACS_NONE |\n--\ndrivers/net/phy/intel-xway.c-263-\t\t XWAY_MMD_LEDCH_FBF_F16HZ);\ndrivers/net/phy/intel-xway.c:264:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LEDCL,\ndrivers/net/phy/intel-xway.c-265-\t\t XWAY_MMD_LEDCH_CBLINK_NONE |\n--\ndrivers/net/phy/intel-xway.c-276-\t\tXWAY_MMD_LEDxL_BLINKS_NONE;\ndrivers/net/phy/intel-xway.c:277:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED0H, ledxh);\ndrivers/net/phy/intel-xway.c:278:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED0L, ledxl);\ndrivers/net/phy/intel-xway.c:279:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED1H, ledxh);\ndrivers/net/phy/intel-xway.c:280:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED1L, ledxl);\ndrivers/net/phy/intel-xway.c:281:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED2H, ledxh);\ndrivers/net/phy/intel-xway.c:282:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED2L, ledxl);\ndrivers/net/phy/intel-xway.c-283-\n--\ndrivers/net/phy/intel-xway.c=393=static int xway_gphy_led_brightness_set(struct phy_device *phydev,\n--\ndrivers/net/phy/intel-xway.c-410-\tif (value == LED_OFF) {\ndrivers/net/phy/intel-xway.c:411:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LEDxH(index), 0);\ndrivers/net/phy/intel-xway.c-412-\t\tif (ret)\n--\ndrivers/net/phy/intel-xway.c-414-\ndrivers/net/phy/intel-xway.c:415:\t\treturn phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LEDxL(index), 0);\ndrivers/net/phy/intel-xway.c-416-\t} else {\n--\n\n"
} |
| 19/2 | 2026/08/06 16:23 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 20588 output: 36 thoughts: 79 Thoughts: Okay, let me break this down. **Tracing the MMD Write Function Calls** Hmm, so `rtlgen_write_mmd` is definitely the target here. I need to understand how it's being invoked. Right, it's called from `rtl822x_write_mmd`. And that function, `rtl822x_write_mmd`, is the `.write_mmd` function for the `realtek_drvs` structure. That tells me a lot – it's part of the Realtek driver family, likely interacting directly with the hardware. Then, there's `phy_write_mmd`, and that's an interesting one because it's the generic PHY abstraction layer. It's supposed to invoke its own `.write_mmd` function if one is defined. So, there is a good chance that `phy_write_mmd` is the one that's supposed to be calling `rtl822x_write_mmd` which ultimately calls `rtlgen_write_mmd`. To be certain, and to solidify my understanding of the execution path, I need to double-check the implementation of `phy_write_mmd`. It is the crucial junction in this chain of calls. I need to make sure the assumptions about how `phy_write_mmd` handles its `.write_mmd` function pointer are correct. Let's verify that. |
| 20/2 | 2026/08/06 16:23 | tool | grepper |
0mError:no matches Args: {
"Expression": "int phy_write_mmd",
"PathPrefix": "drivers/net/phy/phy.c"
}Results: {
"error": "no matches"
} |
| 21/2 | 2026/08/06 16:23 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 21025 output: 38 thoughts: 20 Thoughts: Here's my thought process, as it stands: **Navigating the PHY Driver** Okay, so I need to find the definition or usage of `phy_write_mmd`. It's likely within the `phy_device.c` file, given the naming convention. That's the logical starting point. I'll need to open that up and either search directly for the function name or maybe trace its calls if it's not a direct implementation but rather a wrapper or abstraction. Understanding how `phy_write_mmd` works is crucial; it might be responsible for direct access to the Management Mode Device registers within the PHY, so I need to understand its context within the broader PHY driver structure. I'll likely be looking for things like register addresses, data formatting, potential error handling, and how it interacts with the underlying bus – likely MDIO, but confirmation is needed. Let's get to it. |
| 22/2 | 2026/08/06 16:23 | tool | grepper |
0mError:no matches Args: {
"Expression": "int phy_write_mmd",
"PathPrefix": "drivers/net/phy/phy_device.c"
}Results: {
"error": "no matches"
} |
| 23/2 | 2026/08/06 16:23 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 21291 output: 33 thoughts: 36 Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person: **Locating the PHY Write Function** Right, so I'm looking for the definition or declaration of `phy_write_mmd`. Based on the context, that's almost certainly a function related to writing to a Management Mode Device (MMD) within a PHY (Physical Layer). Given my experience, the logical place to start digging would be within the network device driver infrastructure. `drivers/net/phy` is the obvious top-level directory to begin my search. More specifically, `phy_core.c` is usually the repository for the core PHY driver functions, the ones that are likely shared among different PHY driver implementations. I'd expect to find the actual function definition there. Alternatively, I might find a declaration or prototype in the corresponding header file, which is probably `include/linux/phy.h`. That header would define the PHY API and data structures. It's a quick check to see if the function is declared there before I start searching the source file. It is the logical order to start my search. |
| 24/2 | 2026/08/06 16:23 | tool | grepper |
0mArgs:{
"Expression": "int phy_write_mmd",
"PathPrefix": "drivers/net/phy/"
}Results: {
"Output": "drivers/net/phy/phy-core.c=523=EXPORT_SYMBOL(__phy_write_mmd);\n--\ndrivers/net/phy/phy-core.c-534- */\ndrivers/net/phy/phy-core.c:535:int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)\ndrivers/net/phy/phy-core.c-536-{\n"
} |
| 25/2 | 2026/08/06 16:23 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 21726 output: 39 thoughts: 20 Thoughts: Here's a summary of my thought process, as requested: **Diving into PHY Core Code** Alright, let's get down to brass tacks. I need to understand what's happening with this PHY module, and the function `phy_write_mmd` seems like a key area to dissect. My experience tells me that MMD, or Mode/Register Map, is a common technique within the PHY realm, where you select a "mode" or register bank using an address and then interact with the specific registers within that selected bank. Given my expertise, I'm already anticipating that the `phy_write_mmd` function probably handles the low-level writes to this MMD interface. I'm keen to see if it's abstracted for multiple PHY types or implemented specifically for a narrow range. I need to understand the data structures it operates on. I'm also interested to see the error checking and how the function handles possible I2C or SPI write failures. What assumptions does it make about the underlying bus? Does it have any debug or logging capabilities I can leverage? My goal is to grasp its functionality. Time to dig in! |
| 26/2 | 2026/08/06 16:24 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/phy-core.c",
"FirstLine": 535,
"LineCount": 20
}Results: {
"Contents": " 535:\tint phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)\n 536:\t{\n 537:\t\tint ret;\n 538:\t\n 539:\t\tphy_lock_mdio_bus(phydev);\n 540:\t\tret = __phy_write_mmd(phydev, devad, regnum, val);\n 541:\t\tphy_unlock_mdio_bus(phydev);\n 542:\t\n 543:\t\treturn ret;\n 544:\t}\n 545:\tEXPORT_SYMBOL(phy_write_mmd);\n 546:\t\n 547:\t/**\n 548:\t * phy_modify_changed - Function for modifying a PHY register\n 549:\t * @phydev: the phy_device struct\n 550:\t * @regnum: register number to modify\n 551:\t * @mask: bit mask of bits to clear\n 552:\t * @set: new value of bits set in mask to write to @regnum\n 553:\t *\n 554:\t * NOTE: MUST NOT be called from interrupt context,\n"
} |
| 27/2 | 2026/08/06 16:24 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 22343 output: 39 thoughts: 13 Thoughts: Okay, here's my attempt at summarizing the thought process, as requested, geared toward an expert audience, and written in the first person: **Diving into `__phy_write_mmd`** Alright, let's take a look at this `__phy_write_mmd` function. Immediately, my mind starts to race. This name suggests it's a low-level, internal function related to writing to something within the PHY, probably some register or memory-mapped data space. The `__` prefix is a strong indicator of an internal API, a function not intended for direct use by the general driver code. This tells me it's likely a critical component, potentially handling the actual bus transactions or register access patterns. I'm instantly wondering about the context. What PHY is this related to? Is it a specific type, like Ethernet, PCIe, or something else entirely? The "mmd" part is intriguing. Is it related to the "Message Mode Device" or something similar? I'd need to dig deeper into the header files or associated documentation to understand the specifics of the hardware abstraction being used. I'll need to know the underlying bus, be it I2C, SPI, or a custom one, to fully grasp its function. Then I'm already thinking about potential error scenarios. What kind of error handling is implemented? Does it check for write timeouts or bus errors? Is there any retry logic? Does it log errors in a useful way or just return a generic error code? Considering the criticality of these types of routines, robust error handling is paramount. If a write fails, it can impact entire system operation, therefore I should be checking for the error-handling method used. I also wonder about concurrency issues. Is this function re-entrant? Does it need any kind of mutex or semaphore to protect shared resources, particularly if it's operating on a shared memory map? Any multithreading in the driver context would need that protection to remain stable. My next step would be to trace its calls and see where and how it's used. Knowing the calling functions will give me significant insight into the data being written, the purpose of the write, and the overall driver architecture. Ultimately, I'd want to understand the complete data path for writing. Finally, I'll need to scrutinize the code itself. I'd be looking for: * **Register offsets and their interpretations**: Are they clearly defined? Are there any comments explaining what each bitfield represents? * **Data packing**: Is the data being packed or unpacked correctly? What's the byte order? * **Bus transactions**: How are the bus cycles being orchestrated? Is there any optimization going on? * **Potential for optimization**: Is there any overhead that could be minimized? Is it using the appropriate bus width, or the minimum number of transactions possible? Essentially, I'm expecting this `__phy_write_mmd` function to be a key building block in a hardware abstraction layer, and my analysis would involve quickly dissecting its role and potential vulnerabilities within that layer. |
| 28/2 | 2026/08/06 16:24 | tool | grepper |
0mArgs:{
"Expression": "int __phy_write_mmd",
"PathPrefix": "drivers/net/phy/phy-core.c"
}Results: {
"Output": "drivers/net/phy/phy-core.c=500=EXPORT_SYMBOL(phy_read_mmd);\n--\ndrivers/net/phy/phy-core.c-511- */\ndrivers/net/phy/phy-core.c:512:int __phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)\ndrivers/net/phy/phy-core.c-513-{\n"
} |
| 29/2 | 2026/08/06 16:24 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 23169 output: 39 thoughts: 13 Thoughts: Okay, let's dive into this. Here's my take on those thoughts, as if they're my own: **Analyzing `__phy_write_mmd`** Alright, time to crack open the code and focus on `__phy_write_mmd`. I need to understand this function. It's clearly a core piece related to writing to the MMD, likely within the PHY (Physical Layer) of this system. I immediately want to grasp its purpose, how it's used, and potential areas of concern for debugging or optimization, given my expertise. I need to figure out what it's writing, how it determines the values, and where this data is coming from. |
| 30/2 | 2026/08/06 16:24 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/phy-core.c",
"FirstLine": 512,
"LineCount": 20
}Results: {
"Contents": " 512:\tint __phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)\n 513:\t{\n 514:\t\tif (regnum \u003e (u16)~0 || devad \u003e 32)\n 515:\t\t\treturn -EINVAL;\n 516:\t\n 517:\t\tif (phydev-\u003edrv \u0026\u0026 phydev-\u003edrv-\u003ewrite_mmd)\n 518:\t\t\treturn phydev-\u003edrv-\u003ewrite_mmd(phydev, devad, regnum, val);\n 519:\t\n 520:\t\treturn mmd_phy_write(phydev-\u003emdio.bus, phydev-\u003emdio.addr,\n 521:\t\t\t\t phydev-\u003eis_c45, devad, regnum, val);\n 522:\t}\n 523:\tEXPORT_SYMBOL(__phy_write_mmd);\n 524:\t\n 525:\t/**\n 526:\t * phy_write_mmd - Convenience function for writing a register\n 527:\t * on an MMD on a given PHY.\n 528:\t * @phydev: The phy_device struct\n 529:\t * @devad: The MMD to read from\n 530:\t * @regnum: The register on the MMD to read\n 531:\t * @val: value to write to @regnum\n"
} |
| 31/2 | 2026/08/06 16:24 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 23735 output: 31 thoughts: 82 Thoughts: **Analyzing the Realtek PHY Write Mechanism** Okay, so I'm tracing through this code, trying to understand how this Realtek PHY write functionality works. It looks like the core operation is triggered by `phydev->drv->write_mmd`. Right, and based on the context, that's being handled by `rtlgen_write_mmd`. So that's the Realtek-specific implementation of the MMD write. Now, the key question for me is, can this be accessed from userspace? Is there a path? Ah, yes, the `SIOCSMIIREG` ioctl. Right, that's the standard way to interact with the MII/MDIO interface from userspace. So, it's definitely accessible, which is critical to understand. Time to dive into `phy_mii_ioctl` and see exactly how that ioctl call maps onto this MMD write path. Understanding the `phy_mii_ioctl` is the key to understanding the full flow. |
| 32/2 | 2026/08/06 16:24 | tool | grepper |
0mArgs:{
"Expression": "phy_mii_ioctl",
"PathPrefix": "drivers/net/phy/"
}Results: {
"Output": "drivers/net/phy/phy.c=298=EXPORT_SYMBOL(phy_ethtool_ksettings_get);\n--\ndrivers/net/phy/phy.c-300-/**\ndrivers/net/phy/phy.c:301: * phy_mii_ioctl - generic PHY MII ioctl interface\ndrivers/net/phy/phy.c-302- * @phydev: the phy_device struct\n--\ndrivers/net/phy/phy.c-309- */\ndrivers/net/phy/phy.c:310:int phy_mii_ioctl(struct phy_device *phydev, struct ifreq *ifr, int cmd)\ndrivers/net/phy/phy.c-311-{\n--\ndrivers/net/phy/phy.c-430-}\ndrivers/net/phy/phy.c:431:EXPORT_SYMBOL(phy_mii_ioctl);\ndrivers/net/phy/phy.c-432-\n--\ndrivers/net/phy/phy.c=439=int phy_do_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)\n--\ndrivers/net/phy/phy.c-443-\ndrivers/net/phy/phy.c:444:\treturn phy_mii_ioctl(dev-\u003ephydev, ifr, cmd);\ndrivers/net/phy/phy.c-445-}\n--\ndrivers/net/phy/phylink.c=3524=int phylink_mii_ioctl(struct phylink *pl, struct ifreq *ifr, int cmd)\n--\ndrivers/net/phy/phylink.c-3551-\t\tdefault:\ndrivers/net/phy/phylink.c:3552:\t\t\tret = phy_mii_ioctl(pl-\u003ephydev, ifr, cmd);\ndrivers/net/phy/phylink.c-3553-\t\t\tbreak;\n"
} |
| 33/2 | 2026/08/06 16:24 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 24528 output: 37 thoughts: 11 Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person: **Analyzing the Call to `phy_mii_ioctl`** Alright, let's dive into this `phy_mii_ioctl` function call. My initial thought process is geared towards understanding its context within the broader network stack. It's a key piece of the puzzle, likely responsible for mediating interactions between the Media Independent Interface (MII) or Reduced MII (RMII) and the upper-level network driver. My immediate questions are: What's the target platform? What's the kernel version? Knowing this will help understand any potential platform-specific quirks. I'm going to start by tracing the function's definition, looking for its arguments. It's safe to assume it's handling `ioctl` calls related to PHY (Physical Layer) management, which could include reading/writing registers, resetting the PHY, autonegotiation control, link status retrieval, and so on. The next thing I'll be looking for is the data structure passed to the function, probably some sort of `mii_ioctl_data` or similar. I expect it to have a `cmd` field, which I need to understand. Is it a standard set of `ioctl` commands defined by the kernel, or are we dealing with custom ones for this specific driver and PHY chip? The specific `cmd` value will drive my subsequent analysis. I'll be paying close attention to any error handling. Are there sufficient checks for invalid command values, out-of-range register accesses, or potential hardware issues? I'm going to want to confirm if the driver properly implements locking to prevent race conditions when multiple threads access the PHY concurrently. And I will look for any potential for deadlocks. I also expect to see a call to the underlying PHY driver's read/write functions (e.g., `phy_read`, `phy_write`). I'll need to understand how these interact with the specific PHY chip. I want to see if the driver is correctly handling any PHY-specific idiosyncrasies, such as register offsets or bitfield definitions. I'll want to check if the driver supports all the defined states and modes, like autonegotiation, forced speed, and duplex settings. Finally, I'll be looking for any potential security vulnerabilities, like unchecked user-provided input that could lead to register corruption or other exploits. |
| 34/2 | 2026/08/06 16:24 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/phy.c",
"FirstLine": 310,
"LineCount": 50
}Results: {
"Contents": " 310:\tint phy_mii_ioctl(struct phy_device *phydev, struct ifreq *ifr, int cmd)\n 311:\t{\n 312:\t\tstruct mii_ioctl_data *mii_data = if_mii(ifr);\n 313:\t\tstruct kernel_hwtstamp_config kernel_cfg;\n 314:\t\tstruct netlink_ext_ack extack = {};\n 315:\t\tu16 val = mii_data-\u003eval_in;\n 316:\t\tbool change_autoneg = false;\n 317:\t\tstruct hwtstamp_config cfg;\n 318:\t\tint prtad, devad;\n 319:\t\tint ret;\n 320:\t\n 321:\t\tswitch (cmd) {\n 322:\t\tcase SIOCGMIIPHY:\n 323:\t\t\tmii_data-\u003ephy_id = phydev-\u003emdio.addr;\n 324:\t\t\tfallthrough;\n 325:\t\n 326:\t\tcase SIOCGMIIREG:\n 327:\t\t\tif (mdio_phy_id_is_c45(mii_data-\u003ephy_id)) {\n 328:\t\t\t\tprtad = mdio_phy_id_prtad(mii_data-\u003ephy_id);\n 329:\t\t\t\tdevad = mdio_phy_id_devad(mii_data-\u003ephy_id);\n 330:\t\t\t\tret = mdiobus_c45_read(phydev-\u003emdio.bus, prtad, devad,\n 331:\t\t\t\t\t\t mii_data-\u003ereg_num);\n 332:\t\n 333:\t\t\t} else {\n 334:\t\t\t\tret = mdiobus_read(phydev-\u003emdio.bus, mii_data-\u003ephy_id,\n 335:\t\t\t\t\t\t mii_data-\u003ereg_num);\n 336:\t\t\t}\n 337:\t\n 338:\t\t\tif (ret \u003c 0)\n 339:\t\t\t\treturn ret;\n 340:\t\n 341:\t\t\tmii_data-\u003eval_out = ret;\n 342:\t\n 343:\t\t\treturn 0;\n 344:\t\n 345:\t\tcase SIOCSMIIREG:\n 346:\t\t\tif (mdio_phy_id_is_c45(mii_data-\u003ephy_id)) {\n 347:\t\t\t\tprtad = mdio_phy_id_prtad(mii_data-\u003ephy_id);\n 348:\t\t\t\tdevad = mdio_phy_id_devad(mii_data-\u003ephy_id);\n 349:\t\t\t} else {\n 350:\t\t\t\tprtad = mii_data-\u003ephy_id;\n 351:\t\t\t\tdevad = mii_data-\u003ereg_num;\n 352:\t\t\t}\n 353:\t\t\tif (prtad == phydev-\u003emdio.addr) {\n 354:\t\t\t\tswitch (devad) {\n 355:\t\t\t\tcase MII_BMCR:\n 356:\t\t\t\t\tif ((val \u0026 (BMCR_RESET | BMCR_ANENABLE)) == 0) {\n 357:\t\t\t\t\t\tif (phydev-\u003eautoneg == AUTONEG_ENABLE)\n 358:\t\t\t\t\t\t\tchange_autoneg = true;\n 359:\t\t\t\t\t\tphydev-\u003eautoneg = AUTONEG_DISABLE;\n"
} |
| 35/2 | 2026/08/06 16:24 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 25942 output: 37 thoughts: 45 Thoughts: Okay, here's my interpretation of that thought process, from an expert's perspective: **Diving into the PHY MII IOCTL** Alright, hang on a second. I need to make sure I understand the low-level details of this driver. When `SIOCSMIIREG` gets called, is it using the more specific `mdiobus_c45_write` function, or the general `mdiobus_write`? I need to be precise about how this MII register write is being handled. The devil is always in the details, especially with PHY interaction. I should take a look at the rest of `phy_mii_ioctl` and verify the exact path of the write operation. Gotta make sure it's the expected one for the given PHY type. |
| 36/2 | 2026/08/06 16:24 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/phy.c",
"FirstLine": 360,
"LineCount": 50
}Results: {
"Contents": " 360:\t\t\t\t\t\tif (val \u0026 BMCR_FULLDPLX)\n 361:\t\t\t\t\t\t\tphydev-\u003eduplex = DUPLEX_FULL;\n 362:\t\t\t\t\t\telse\n 363:\t\t\t\t\t\t\tphydev-\u003eduplex = DUPLEX_HALF;\n 364:\t\t\t\t\t\tif (val \u0026 BMCR_SPEED1000)\n 365:\t\t\t\t\t\t\tphydev-\u003espeed = SPEED_1000;\n 366:\t\t\t\t\t\telse if (val \u0026 BMCR_SPEED100)\n 367:\t\t\t\t\t\t\tphydev-\u003espeed = SPEED_100;\n 368:\t\t\t\t\t\telse phydev-\u003espeed = SPEED_10;\n 369:\t\t\t\t\t} else {\n 370:\t\t\t\t\t\tif (phydev-\u003eautoneg == AUTONEG_DISABLE)\n 371:\t\t\t\t\t\t\tchange_autoneg = true;\n 372:\t\t\t\t\t\tphydev-\u003eautoneg = AUTONEG_ENABLE;\n 373:\t\t\t\t\t}\n 374:\t\t\t\t\tbreak;\n 375:\t\t\t\tcase MII_ADVERTISE:\n 376:\t\t\t\t\tmii_adv_mod_linkmode_adv_t(phydev-\u003eadvertising,\n 377:\t\t\t\t\t\t\t\t val);\n 378:\t\t\t\t\tchange_autoneg = true;\n 379:\t\t\t\t\tbreak;\n 380:\t\t\t\tcase MII_CTRL1000:\n 381:\t\t\t\t\tmii_ctrl1000_mod_linkmode_adv_t(phydev-\u003eadvertising,\n 382:\t\t\t\t\t\t\t\t val);\n 383:\t\t\t\t\tchange_autoneg = true;\n 384:\t\t\t\t\tbreak;\n 385:\t\t\t\tdefault:\n 386:\t\t\t\t\t/* do nothing */\n 387:\t\t\t\t\tbreak;\n 388:\t\t\t\t}\n 389:\t\t\t}\n 390:\t\n 391:\t\t\tif (mdio_phy_id_is_c45(mii_data-\u003ephy_id))\n 392:\t\t\t\tmdiobus_c45_write(phydev-\u003emdio.bus, prtad, devad,\n 393:\t\t\t\t\t\t mii_data-\u003ereg_num, val);\n 394:\t\t\telse\n 395:\t\t\t\tmdiobus_write(phydev-\u003emdio.bus, prtad, devad, val);\n 396:\t\n 397:\t\t\tif (prtad == phydev-\u003emdio.addr \u0026\u0026\n 398:\t\t\t devad == MII_BMCR \u0026\u0026\n 399:\t\t\t val \u0026 BMCR_RESET)\n 400:\t\t\t\treturn phy_init_hw(phydev);\n 401:\t\n 402:\t\t\tif (change_autoneg)\n 403:\t\t\t\treturn phy_start_aneg(phydev);\n 404:\t\n 405:\t\t\treturn 0;\n 406:\t\n 407:\t\tcase SIOCSHWTSTAMP:\n 408:\t\t\tif (phydev-\u003emii_ts \u0026\u0026 phydev-\u003emii_ts-\u003ehwtstamp_set) {\n 409:\t\t\t\tif (copy_from_user(\u0026cfg, ifr-\u003eifr_data, sizeof(cfg)))\n"
} |
| 37/2 | 2026/08/06 16:24 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 26975 output: 35 thoughts: 215 Thoughts: **Tracing the PHY MMD Write Function Calls** Okay, so I'm looking at `phy_mii_ioctl` and I'm pretty sure it *doesn't* directly call `phy_write_mmd`. That's the starting point. My initial thought was that it would, but now I need to figure out the actual call chain. Now, I see that `phy_write_mmd` gets called from `genphy_write_mmd_c45`, wait a minute, no that is a callback function. I need to trace this more carefully. Let me see... where *is* `phy_write_mmd` actually getting called? Hmm, it looks like `phy_write_mmd` gets called in `rtlgen_write_mmd`? No, wait a minute, `rtlgen_write_mmd` is just the implementation for `.write_mmd`. So, I need to know where `.write_mmd` itself is being called. Right, here we go... looks like `.write_mmd` is called in `__phy_write_mmd`. That's the key. And `__phy_write_mmd` is *directly* called by `phy_write_mmd` itself. Okay, that's not too surprising. Now, the important part. `phy_write_mmd` is the workhorse. I see it gets called from a bunch of places within the various PHY driver implementations - as expected, that makes sense. And, I see it's also called by some of the more higher-level functions like `phy_init_eee` and `phy_ethtool_set_eee` and other PHY configuration routines. So, its a critical piece of the puzzle, and used broadly. |
| 38/2 | 2026/08/06 16:25 | tool | grepper |
0mError:no matches Args: {
"Expression": "phy_write_mmd",
"PathPrefix": "drivers/net/phy/phy.c"
}Results: {
"error": "no matches"
} |
| 39/2 | 2026/08/06 16:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 27624 output: 32 thoughts: 18 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: **Investigating Energy Efficient Ethernet (EEE) Configuration** Alright, so we're looking at Ethernet energy efficiency, and I need to figure out where the relevant configuration settings are. Given what I'm dealing with, my first hunch is to dive right into the low-level PHY settings. Specifically, I'm thinking about examining the `phy_ethtool_set_eee` function (or something functionally equivalent if the system utilizes a custom or vendor-specific naming convention). It's a pretty standard approach, so that's where I'd start. I suspect that's where I can find the control points to adjust EEE capabilities. If that doesn't yield results, I'd trace back from there. |
| 40/2 | 2026/08/06 16:25 | tool | grepper |
0mArgs:{
"Expression": "phy_write_mmd",
"PathPrefix": "drivers/net/phy/"
}Results: {
"Output": "\nFull output is too long, showing 500 out of 1828 lines.\nUse more precise expression if possible.\n\ndrivers/net/phy/adin.c=275=static int adin_config_rgmii_mode(struct phy_device *phydev)\n--\ndrivers/net/phy/adin.c-316-\ndrivers/net/phy/adin.c:317:\treturn phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/adin.c-318-\t\t\t ADIN1300_GE_RGMII_CFG_REG, reg);\n--\ndrivers/net/phy/adin.c=321=static int adin_config_rmii_mode(struct phy_device *phydev)\n--\ndrivers/net/phy/adin.c-343-\ndrivers/net/phy/adin.c:344:\treturn phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/adin.c-345-\t\t\t ADIN1300_GE_RMII_CFG_REG, reg);\n--\ndrivers/net/phy/adin1100.c=192=static int adin_set_powerdown_mode(struct phy_device *phydev, bool en)\n--\ndrivers/net/phy/adin1100.c-195-\ndrivers/net/phy/adin1100.c:196:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/adin1100.c-197-\t\t\t ADIN_CRSM_SFT_PD_CNTRL,\n--\ndrivers/net/phy/adin1140-phy.c=46=static struct phy_driver adin1140_driver[] = {\n--\ndrivers/net/phy/adin1140-phy.c-54-\t\t.read_mmd = genphy_read_mmd_c45,\ndrivers/net/phy/adin1140-phy.c:55:\t\t.write_mmd = genphy_write_mmd_c45,\ndrivers/net/phy/adin1140-phy.c-56-\t\t.get_plca_cfg = genphy_c45_plca_get_cfg,\n--\ndrivers/net/phy/air_an8801.c=272=static int an8801r_led_blink_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/air_an8801.c-300-\t\t\t\t LED_BLINK_DUR_MASK);\ndrivers/net/phy/air_an8801.c:301:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, LED_BLINK_DUR,\ndrivers/net/phy/air_an8801.c-302-\t\t\t\t blink_dur);\n--\ndrivers/net/phy/air_an8801.c-305-\ndrivers/net/phy/air_an8801.c:306:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, LED_ON_DUR,\ndrivers/net/phy/air_an8801.c-307-\t\t\t\t hw_delay_on);\n--\ndrivers/net/phy/air_an8801.c=902=static int an8801r_config_init(struct phy_device *phydev)\n--\ndrivers/net/phy/air_an8801.c-911-\t/* Disable Low Power Mode (LPM) */\ndrivers/net/phy/air_an8801.c:912:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, AN8801_REG_PHY_INTERNAL0,\ndrivers/net/phy/air_an8801.c-913-\t\t\t FIELD_PREP(AN8801_PHY_INTFUNC_MASK, 0x1e));\n--\ndrivers/net/phy/air_an8801.c-916-\ndrivers/net/phy/air_an8801.c:917:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, AN8801_REG_PHY_INTERNAL1,\ndrivers/net/phy/air_an8801.c-918-\t\t\t FIELD_PREP(AN8801_PHY_INTFUNC_MASK, 0x2));\n--\ndrivers/net/phy/air_an8801.c-957-\ndrivers/net/phy/air_an8801.c:958:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/air_an8801.c-959-\t\t\t AN8801_PHY_TX_PAIR_DLY_SEL_GBE,\n--\ndrivers/net/phy/air_an8801.c-964-\ndrivers/net/phy/air_an8801.c:965:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AN8801_PHY_RXADC_CTRL,\ndrivers/net/phy/air_an8801.c-966-\t\t\t AN8801_PHY_RXADC_SAMP_PHSEL_A |\n--\ndrivers/net/phy/air_an8801.c-970-\ndrivers/net/phy/air_an8801.c:971:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AN8801_PHY_RXADC_REV_0,\ndrivers/net/phy/air_an8801.c-972-\t\t\t FIELD_PREP(AN8801_PHY_RXADC_REV_MASK_A, 1));\n--\ndrivers/net/phy/air_an8801.c-975-\ndrivers/net/phy/air_an8801.c:976:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AN8801_PHY_RXADC_REV_1,\ndrivers/net/phy/air_an8801.c-977-\t\t\t FIELD_PREP(AN8801_PHY_RXADC_REV_MASK_C, 1));\n--\ndrivers/net/phy/air_en8811h.c=610=static int air_hw_led_blink_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/air_en8811h.c-628-\tif (changed)\ndrivers/net/phy/air_en8811h.c:629:\t\treturn phy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/air_en8811h.c-630-\t\t\t\t AIR_PHY_LED_BLINK(index),\n--\ndrivers/net/phy/air_en8811h.c=708=static int air_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/air_en8811h.c-764-\ndrivers/net/phy/air_en8811h.c:765:\treturn phy_write_mmd(phydev, MDIO_MMD_VEND2, AIR_PHY_LED_BLINK(index),\ndrivers/net/phy/air_en8811h.c-766-\t\t\t blink);\n--\ndrivers/net/phy/air_en8811h.c=797=static int air_leds_init(struct phy_device *phydev, int num, int dur, int mode)\n--\ndrivers/net/phy/air_en8811h.c-801-\ndrivers/net/phy/air_en8811h.c:802:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, AIR_PHY_LED_DUR_BLINK,\ndrivers/net/phy/air_en8811h.c-803-\t\t\t dur);\n--\ndrivers/net/phy/air_en8811h.c-806-\ndrivers/net/phy/air_en8811h.c:807:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, AIR_PHY_LED_DUR_ON,\ndrivers/net/phy/air_en8811h.c-808-\t\t\t dur \u003e\u003e 1);\n--\ndrivers/net/phy/air_en8811h.c=1281=static int en8811h_config_init(struct phy_device *phydev)\n--\ndrivers/net/phy/air_en8811h.c-1298-\t */\ndrivers/net/phy/air_en8811h.c:1299:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_MCU_CMD_1,\ndrivers/net/phy/air_en8811h.c-1300-\t\t\t AIR_PHY_MCU_CMD_1_MODE1);\n--\ndrivers/net/phy/air_en8811h.c-1302-\t\treturn ret;\ndrivers/net/phy/air_en8811h.c:1303:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_MCU_CMD_2,\ndrivers/net/phy/air_en8811h.c-1304-\t\t\t AIR_PHY_MCU_CMD_2_MODE1);\n--\ndrivers/net/phy/air_en8811h.c-1306-\t\treturn ret;\ndrivers/net/phy/air_en8811h.c:1307:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_MCU_CMD_3,\ndrivers/net/phy/air_en8811h.c-1308-\t\t\t AIR_PHY_MCU_CMD_3_MODE1);\n--\ndrivers/net/phy/air_en8811h.c-1310-\t\treturn ret;\ndrivers/net/phy/air_en8811h.c:1311:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_MCU_CMD_4,\ndrivers/net/phy/air_en8811h.c-1312-\t\t\t AIR_PHY_MCU_CMD_4_MODE1);\n--\ndrivers/net/phy/air_en8811h.c=1452=static int en8811h_clear_intr(struct phy_device *phydev)\n--\ndrivers/net/phy/air_en8811h.c-1455-\ndrivers/net/phy/air_en8811h.c:1456:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_MCU_CMD_3,\ndrivers/net/phy/air_en8811h.c-1457-\t\t\t AIR_PHY_MCU_CMD_3_DOCMD);\n--\ndrivers/net/phy/air_en8811h.c-1460-\ndrivers/net/phy/air_en8811h.c:1461:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_MCU_CMD_4,\ndrivers/net/phy/air_en8811h.c-1462-\t\t\t AIR_PHY_MCU_CMD_4_INTCLR);\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c=90=static int aqr_fw_load_memory(struct phy_device *phydev, u32 addr,\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c-95-\ndrivers/net/phy/aquantia/aquantia_firmware.c:96:\tphy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/aquantia/aquantia_firmware.c-97-\t\t VEND1_GLOBAL_MAILBOX_INTERFACE1,\ndrivers/net/phy/aquantia/aquantia_firmware.c-98-\t\t VEND1_GLOBAL_MAILBOX_INTERFACE1_CRC_RESET);\ndrivers/net/phy/aquantia/aquantia_firmware.c:99:\tphy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/aquantia/aquantia_firmware.c-100-\t\t VEND1_GLOBAL_MAILBOX_INTERFACE3,\ndrivers/net/phy/aquantia/aquantia_firmware.c-101-\t\t VEND1_GLOBAL_MAILBOX_INTERFACE3_MSW_ADDR(addr));\ndrivers/net/phy/aquantia/aquantia_firmware.c:102:\tphy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/aquantia/aquantia_firmware.c-103-\t\t VEND1_GLOBAL_MAILBOX_INTERFACE4,\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c-115-\ndrivers/net/phy/aquantia/aquantia_firmware.c:116:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_MAILBOX_INTERFACE5,\ndrivers/net/phy/aquantia/aquantia_firmware.c-117-\t\t\t VEND1_GLOBAL_MAILBOX_INTERFACE5_MSW_DATA(word));\ndrivers/net/phy/aquantia/aquantia_firmware.c:118:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_MAILBOX_INTERFACE6,\ndrivers/net/phy/aquantia/aquantia_firmware.c-119-\t\t\t VEND1_GLOBAL_MAILBOX_INTERFACE6_LSW_DATA(word));\ndrivers/net/phy/aquantia/aquantia_firmware.c-120-\ndrivers/net/phy/aquantia/aquantia_firmware.c:121:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_MAILBOX_INTERFACE1,\ndrivers/net/phy/aquantia/aquantia_firmware.c-122-\t\t\t VEND1_GLOBAL_MAILBOX_INTERFACE1_EXECUTE |\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c=149=static int aqr_fw_boot(struct phy_device *phydev, const u8 *data, size_t size,\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c-261-\t/* stall the microcprocessor */\ndrivers/net/phy/aquantia/aquantia_firmware.c:262:\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_CONTROL2,\ndrivers/net/phy/aquantia/aquantia_firmware.c-263-\t\t VEND1_GLOBAL_CONTROL2_UP_RUN_STALL | VEND1_GLOBAL_CONTROL2_UP_RUN_STALL_OVD);\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c-283-\t/* Release the microprocessor. UP_RESET must be held for 100 usec. */\ndrivers/net/phy/aquantia/aquantia_firmware.c:284:\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_CONTROL2,\ndrivers/net/phy/aquantia/aquantia_firmware.c-285-\t\t VEND1_GLOBAL_CONTROL2_UP_RUN_STALL |\n--\ndrivers/net/phy/aquantia/aquantia_firmware.c-289-\ndrivers/net/phy/aquantia/aquantia_firmware.c:290:\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_CONTROL2,\ndrivers/net/phy/aquantia/aquantia_firmware.c-291-\t\t VEND1_GLOBAL_CONTROL2_UP_RUN_STALL_OVD);\n--\ndrivers/net/phy/aquantia/aquantia_hwmon.c=55=static int aqr_hwmon_set(struct phy_device *phydev, int reg, long value)\n--\ndrivers/net/phy/aquantia/aquantia_hwmon.c-64-\t/* temp is in s16 range and we're interested in lower 16 bits only */\ndrivers/net/phy/aquantia/aquantia_hwmon.c:65:\treturn phy_write_mmd(phydev, MDIO_MMD_VEND1, reg, (u16)temp);\ndrivers/net/phy/aquantia/aquantia_hwmon.c-66-}\n--\ndrivers/net/phy/aquantia/aquantia_main.c=253=static int aqr_config_intr(struct phy_device *phydev)\n--\ndrivers/net/phy/aquantia/aquantia_main.c-264-\ndrivers/net/phy/aquantia/aquantia_main.c:265:\terr = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_TX_VEND_INT_MASK2,\ndrivers/net/phy/aquantia/aquantia_main.c-266-\t\t\t en ? MDIO_AN_TX_VEND_INT_MASK2_LINK : 0);\n--\ndrivers/net/phy/aquantia/aquantia_main.c-269-\ndrivers/net/phy/aquantia/aquantia_main.c:270:\terr = phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_INT_STD_MASK,\ndrivers/net/phy/aquantia/aquantia_main.c-271-\t\t\t en ? VEND1_GLOBAL_INT_STD_MASK_ALL : 0);\n--\ndrivers/net/phy/aquantia/aquantia_main.c-274-\ndrivers/net/phy/aquantia/aquantia_main.c:275:\terr = phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_INT_VEND_MASK,\ndrivers/net/phy/aquantia/aquantia_main.c-276-\t\t\t en ? VEND1_GLOBAL_INT_VEND_MASK_GLOBAL3 |\n--\ndrivers/net/phy/aquantia/aquantia_main.c=369=static int aqr105_setup_forced(struct phy_device *phydev)\n--\ndrivers/net/phy/aquantia/aquantia_main.c-401-\t}\ndrivers/net/phy/aquantia/aquantia_main.c:402:\tret = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_ADVERTISE, adv);\ndrivers/net/phy/aquantia/aquantia_main.c-403-\tif (ret \u003c 0)\ndrivers/net/phy/aquantia/aquantia_main.c-404-\t\treturn ret;\ndrivers/net/phy/aquantia/aquantia_main.c:405:\tret = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_VEND_PROV, vend);\ndrivers/net/phy/aquantia/aquantia_main.c-406-\tif (ret \u003c 0)\ndrivers/net/phy/aquantia/aquantia_main.c-407-\t\treturn ret;\ndrivers/net/phy/aquantia/aquantia_main.c:408:\tret = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_10GBT_CTRL, ctrl10);\ndrivers/net/phy/aquantia/aquantia_main.c-409-\tif (ret \u003c 0)\n--\ndrivers/net/phy/as21xxx.c=297=static int aeon_firmware_boot(struct phy_device *phydev, const u8 *data,\n--\ndrivers/net/phy/as21xxx.c-307-\ndrivers/net/phy/as21xxx.c:308:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_FW_START_ADDR,\ndrivers/net/phy/as21xxx.c-309-\t\t\t AEON_BOOT_ADDR);\n--\ndrivers/net/phy/as21xxx.c-329-\ndrivers/net/phy/as21xxx.c:330:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/as21xxx.c-331-\t\t\t\t VEND1_GLB_REG_MDIO_INDIRECT_LOAD, val);\n--\ndrivers/net/phy/as21xxx.c-335-\ndrivers/net/phy/as21xxx.c:336:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/as21xxx.c-337-\t\t\t VEND1_GLB_REG_CPU_RESET_ADDR_LO_BASEADDR,\n--\ndrivers/net/phy/as21xxx.c-341-\ndrivers/net/phy/as21xxx.c:342:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1,\ndrivers/net/phy/as21xxx.c-343-\t\t\t VEND1_GLB_REG_CPU_RESET_ADDR_HI_BASEADDR,\n--\ndrivers/net/phy/as21xxx.c=405=static int aeon_ipc_send_cmd(struct phy_device *phydev,\n--\ndrivers/net/phy/as21xxx.c-422-\ndrivers/net/phy/as21xxx.c:423:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_IPC_CMD, cmd);\ndrivers/net/phy/as21xxx.c-424-\tif (ret)\n--\ndrivers/net/phy/as21xxx.c=455=static int aeon_ipc_send_msg(struct phy_device *phydev,\n--\ndrivers/net/phy/as21xxx.c-471-\tfor (i = 0; i \u003c data_len / sizeof(u16); i++)\ndrivers/net/phy/as21xxx.c:472:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_IPC_DATA(i),\ndrivers/net/phy/as21xxx.c-473-\t\t\t data[i]);\n--\ndrivers/net/phy/bcm-phy-lib.c=372=int bcm_phy_set_eee(struct phy_device *phydev, bool enable)\n--\ndrivers/net/phy/bcm-phy-lib.c-385-\ndrivers/net/phy/bcm-phy-lib.c:386:\tphy_write_mmd(phydev, MDIO_MMD_AN, BRCM_CL45VEN_EEE_CONTROL, (u32)val);\ndrivers/net/phy/bcm-phy-lib.c-387-\n--\ndrivers/net/phy/bcm-phy-lib.c-404-\ndrivers/net/phy/bcm-phy-lib.c:405:\tphy_write_mmd(phydev, MDIO_MMD_AN, BCM_CL45VEN_EEE_ADV, (u32)val);\ndrivers/net/phy/bcm-phy-lib.c-406-\n--\ndrivers/net/phy/bcm7xxx.c=628=static int bcm7xxx_28nm_ephy_read_mmd(struct phy_device *phydev,\n--\ndrivers/net/phy/bcm7xxx.c-657-\ndrivers/net/phy/bcm7xxx.c:658:static int bcm7xxx_28nm_ephy_write_mmd(struct phy_device *phydev,\ndrivers/net/phy/bcm7xxx.c-659-\t\t\t\t int devnum, u16 regnum, u16 val)\n--\ndrivers/net/phy/bcm7xxx.c=821=static int bcm7xxx_28nm_probe(struct phy_device *phydev)\n--\ndrivers/net/phy/bcm7xxx.c-886-\t.read_mmd\t= bcm7xxx_28nm_ephy_read_mmd,\t\t\t\\\ndrivers/net/phy/bcm7xxx.c:887:\t.write_mmd\t= bcm7xxx_28nm_ephy_write_mmd,\t\t\t\\\ndrivers/net/phy/bcm7xxx.c-888-}\n--\ndrivers/net/phy/bcm84881.c=99=static int bcm8489x_led_write(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/bcm84881.c-103-\ndrivers/net/phy/bcm84881.c:104:\tret = phy_write_mmd(phydev, MDIO_MMD_PMAPMD,\ndrivers/net/phy/bcm84881.c-105-\t\t\t bcm8489x_led_regs[index].mask_low, low);\n--\ndrivers/net/phy/bcm84881.c-107-\t\treturn ret;\ndrivers/net/phy/bcm84881.c:108:\tret = phy_write_mmd(phydev, MDIO_MMD_PMAPMD,\ndrivers/net/phy/bcm84881.c-109-\t\t\t bcm8489x_led_regs[index].mask_ext, ext);\n--\ndrivers/net/phy/bcm87xx.c=34=static int bcm87xx_of_reg_init(struct phy_device *phydev)\n--\ndrivers/net/phy/bcm87xx.c-68-\ndrivers/net/phy/bcm87xx.c:69:\t\tret = phy_write_mmd(phydev, devid, reg, val);\ndrivers/net/phy/bcm87xx.c-70-\t\tif (ret \u003c 0)\n--\ndrivers/net/phy/bcm87xx.c=140=static int bcm87xx_config_intr(struct phy_device *phydev)\n--\ndrivers/net/phy/bcm87xx.c-154-\t\treg |= 1;\ndrivers/net/phy/bcm87xx.c:155:\t\terr = phy_write_mmd(phydev, MDIO_MMD_PCS,\ndrivers/net/phy/bcm87xx.c-156-\t\t\t\t BCM87XX_LASI_CONTROL, reg);\n--\ndrivers/net/phy/bcm87xx.c-158-\t\treg \u0026= ~1;\ndrivers/net/phy/bcm87xx.c:159:\t\terr = phy_write_mmd(phydev, MDIO_MMD_PCS,\ndrivers/net/phy/bcm87xx.c-160-\t\t\t\t BCM87XX_LASI_CONTROL, reg);\n--\ndrivers/net/phy/dp83822.c=214=static int dp83822_config_wol(struct phy_device *phydev,\n--\ndrivers/net/phy/dp83822.c-229-\t\t */\ndrivers/net/phy/dp83822.c:230:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND2, MII_DP83822_WOL_DA1,\ndrivers/net/phy/dp83822.c-231-\t\t\t (mac[1] \u003c\u003c 8) | mac[0]);\ndrivers/net/phy/dp83822.c:232:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND2, MII_DP83822_WOL_DA2,\ndrivers/net/phy/dp83822.c-233-\t\t\t (mac[3] \u003c\u003c 8) | mac[2]);\ndrivers/net/phy/dp83822.c:234:\t\tphy_write_mmd(phydev, MDIO_MMD_VEND2, MII_DP83822_WOL_DA3,\ndrivers/net/phy/dp83822.c-235-\t\t\t (mac[5] \u003c\u003c 8) | mac[4]);\n--\ndrivers/net/phy/dp83822.c-244-\t\tif (wol-\u003ewolopts \u0026 WAKE_MAGICSECURE) {\ndrivers/net/phy/dp83822.c:245:\t\t\tphy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/dp83822.c-246-\t\t\t\t MII_DP83822_RXSOP1,\ndrivers/net/phy/dp83822.c-247-\t\t\t\t (wol-\u003esopass[1] \u003c\u003c 8) | wol-\u003esopass[0]);\ndrivers/net/phy/dp83822.c:248:\t\t\tphy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/dp83822.c-249-\t\t\t\t MII_DP83822_RXSOP2,\ndrivers/net/phy/dp83822.c-250-\t\t\t\t (wol-\u003esopass[3] \u003c\u003c 8) | wol-\u003esopass[2]);\ndrivers/net/phy/dp83822.c:251:\t\t\tphy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/dp83822.c-252-\t\t\t\t MII_DP83822_RXSOP3,\n--\ndrivers/net/phy/dp83822.c-264-\ndrivers/net/phy/dp83822.c:265:\t\treturn phy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/dp83822.c-266-\t\t\t\t MII_DP83822_WOL_CFG, value);\n--\ndrivers/net/phy/dp83822.c=1045=static int dp83822_resume(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83822.c-1052-\ndrivers/net/phy/dp83822.c:1053:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, MII_DP83822_WOL_CFG, value |\ndrivers/net/phy/dp83822.c-1054-\t\t DP83822_WOL_CLR_INDICATION);\n--\ndrivers/net/phy/dp83867.c=211=static int dp83867_set_wol(struct phy_device *phydev,\n--\ndrivers/net/phy/dp83867.c-231-\ndrivers/net/phy/dp83867.c:232:\t\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFPMD1,\ndrivers/net/phy/dp83867.c-233-\t\t\t\t (mac[1] \u003c\u003c 8 | mac[0]));\ndrivers/net/phy/dp83867.c:234:\t\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFPMD2,\ndrivers/net/phy/dp83867.c-235-\t\t\t\t (mac[3] \u003c\u003c 8 | mac[2]));\ndrivers/net/phy/dp83867.c:236:\t\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFPMD3,\ndrivers/net/phy/dp83867.c-237-\t\t\t\t (mac[5] \u003c\u003c 8 | mac[4]));\n--\ndrivers/net/phy/dp83867.c-244-\t\tif (wol-\u003ewolopts \u0026 WAKE_MAGICSECURE) {\ndrivers/net/phy/dp83867.c:245:\t\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFSOP1,\ndrivers/net/phy/dp83867.c-246-\t\t\t\t (wol-\u003esopass[1] \u003c\u003c 8) | wol-\u003esopass[0]);\ndrivers/net/phy/dp83867.c:247:\t\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFSOP2,\ndrivers/net/phy/dp83867.c-248-\t\t\t\t (wol-\u003esopass[3] \u003c\u003c 8) | wol-\u003esopass[2]);\ndrivers/net/phy/dp83867.c:249:\t\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFSOP3,\ndrivers/net/phy/dp83867.c-250-\t\t\t\t (wol-\u003esopass[5] \u003c\u003c 8) | wol-\u003esopass[4]);\n--\ndrivers/net/phy/dp83867.c-270-\ndrivers/net/phy/dp83867.c:271:\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFCFG, val_rxcfg);\ndrivers/net/phy/dp83867.c-272-\tphy_write(phydev, MII_DP83867_MICR, val_micr);\n--\ndrivers/net/phy/dp83867.c=736=static int dp83867_config_init(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83867.c-808-\ndrivers/net/phy/dp83867.c:809:\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIICTL, val);\ndrivers/net/phy/dp83867.c-810-\ndrivers/net/phy/dp83867.c:811:\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIIDCTL,\ndrivers/net/phy/dp83867.c-812-\t\t\t dp83867-\u003erx_id_delay |\n--\ndrivers/net/phy/dp83867.c-816-\t\tval \u0026= ~DP83867_RGMII_EN;\ndrivers/net/phy/dp83867.c:817:\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIICTL, val);\ndrivers/net/phy/dp83867.c-818-\t}\n--\ndrivers/net/phy/dp83867.c-860-\t\t\tval \u0026= ~DP83867_SGMII_TYPE;\ndrivers/net/phy/dp83867.c:861:\t\tphy_write_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL, val);\ndrivers/net/phy/dp83867.c-862-\n--\ndrivers/net/phy/dp83867.c=935=static int dp83867_phy_reset(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83867.c-953-\t */\ndrivers/net/phy/dp83867.c:954:\terr = phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_DSP_FFE_CFG,\ndrivers/net/phy/dp83867.c-955-\t\t\t 0x0e81);\n--\ndrivers/net/phy/dp83869.c=259=static int dp83869_set_wol(struct phy_device *phydev,\n--\ndrivers/net/phy/dp83869.c-286-\ndrivers/net/phy/dp83869.c:287:\t\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-288-\t\t\t\t\t DP83869_RXFPMD1,\n--\ndrivers/net/phy/dp83869.c-292-\ndrivers/net/phy/dp83869.c:293:\t\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-294-\t\t\t\t\t DP83869_RXFPMD2,\n--\ndrivers/net/phy/dp83869.c-298-\ndrivers/net/phy/dp83869.c:299:\t\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-300-\t\t\t\t\t DP83869_RXFPMD3,\n--\ndrivers/net/phy/dp83869.c-310-\t\tif (wol-\u003ewolopts \u0026 WAKE_MAGICSECURE) {\ndrivers/net/phy/dp83869.c:311:\t\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-312-\t\t\t\t\t DP83869_RXFSOP1,\n--\ndrivers/net/phy/dp83869.c-316-\ndrivers/net/phy/dp83869.c:317:\t\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-318-\t\t\t\t\t DP83869_RXFSOP2,\n--\ndrivers/net/phy/dp83869.c-321-\t\t\t\treturn ret;\ndrivers/net/phy/dp83869.c:322:\t\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-323-\t\t\t\t\t DP83869_RXFSOP3,\n--\ndrivers/net/phy/dp83869.c-346-\ndrivers/net/phy/dp83869.c:347:\tret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RXFCFG, val_rxcfg);\ndrivers/net/phy/dp83869.c-348-\tif (ret)\n--\ndrivers/net/phy/dp83869.c=694=static int dp83869_configure_mode(struct phy_device *phydev,\n--\ndrivers/net/phy/dp83869.c-718-\ndrivers/net/phy/dp83869.c:719:\tret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_OP_MODE,\ndrivers/net/phy/dp83869.c-720-\t\t\t phy_ctrl_val);\n--\ndrivers/net/phy/dp83869.c-753-\ndrivers/net/phy/dp83869.c:754:\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-755-\t\t\t\t DP83869_FX_CTRL, DP83869_FX_CTRL_DEFAULT);\n--\ndrivers/net/phy/dp83869.c-765-\ndrivers/net/phy/dp83869.c:766:\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-767-\t\t\t\t DP83869_FX_CTRL, DP83869_FX_CTRL_DEFAULT);\n--\ndrivers/net/phy/dp83869.c-786-\ndrivers/net/phy/dp83869.c:787:\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-788-\t\t\t\t DP83869_FX_CTRL, DP83869_FX_CTRL_DEFAULT);\n--\ndrivers/net/phy/dp83869.c=804=static int dp83869_config_init(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83869.c-834-\t\t */\ndrivers/net/phy/dp83869.c:835:\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR,\ndrivers/net/phy/dp83869.c-836-\t\t\t\t DP83869_ANA_PLL_PROG_PI, 0x10);\n--\ndrivers/net/phy/dp83869.c-847-\tif (phy_interface_is_rgmii(phydev)) {\ndrivers/net/phy/dp83869.c:848:\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIIDCTL,\ndrivers/net/phy/dp83869.c-849-\t\t\t\t dp83869-\u003erx_int_delay |\n--\ndrivers/net/phy/dp83869.c-867-\ndrivers/net/phy/dp83869.c:868:\t\tret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIICTL,\ndrivers/net/phy/dp83869.c-869-\t\t\t\t val);\n--\ndrivers/net/phy/dp83tc811.c=97=static int dp83811_set_wol(struct phy_device *phydev,\n--\ndrivers/net/phy/dp83tc811.c-112-\t\t */\ndrivers/net/phy/dp83tc811.c:113:\t\tphy_write_mmd(phydev, DP83811_DEVADDR, MII_DP83811_WOL_DA1,\ndrivers/net/phy/dp83tc811.c-114-\t\t\t (mac[1] \u003c\u003c 8) | mac[0]);\ndrivers/net/phy/dp83tc811.c:115:\t\tphy_write_mmd(phydev, DP83811_DEVADDR, MII_DP83811_WOL_DA2,\ndrivers/net/phy/dp83tc811.c-116-\t\t\t (mac[3] \u003c\u003c 8) | mac[2]);\ndrivers/net/phy/dp83tc811.c:117:\t\tphy_write_mmd(phydev, DP83811_DEVADDR, MII_DP83811_WOL_DA3,\ndrivers/net/phy/dp83tc811.c-118-\t\t\t (mac[5] \u003c\u003c 8) | mac[4]);\n--\ndrivers/net/phy/dp83tc811.c-127-\t\tif (wol-\u003ewolopts \u0026 WAKE_MAGICSECURE) {\ndrivers/net/phy/dp83tc811.c:128:\t\t\tphy_write_mmd(phydev, DP83811_DEVADDR,\ndrivers/net/phy/dp83tc811.c-129-\t\t\t\t MII_DP83811_RXSOP1,\ndrivers/net/phy/dp83tc811.c-130-\t\t\t\t (wol-\u003esopass[1] \u003c\u003c 8) | wol-\u003esopass[0]);\ndrivers/net/phy/dp83tc811.c:131:\t\t\tphy_write_mmd(phydev, DP83811_DEVADDR,\ndrivers/net/phy/dp83tc811.c-132-\t\t\t\t MII_DP83811_RXSOP2,\ndrivers/net/phy/dp83tc811.c-133-\t\t\t\t (wol-\u003esopass[3] \u003c\u003c 8) | wol-\u003esopass[2]);\ndrivers/net/phy/dp83tc811.c:134:\t\t\tphy_write_mmd(phydev, DP83811_DEVADDR,\ndrivers/net/phy/dp83tc811.c-135-\t\t\t\t MII_DP83811_RXSOP3,\n--\ndrivers/net/phy/dp83tc811.c-147-\ndrivers/net/phy/dp83tc811.c:148:\t\treturn phy_write_mmd(phydev, DP83811_DEVADDR,\ndrivers/net/phy/dp83tc811.c-149-\t\t\t\t MII_DP83811_WOL_CFG, value);\n--\ndrivers/net/phy/dp83td510.c=530=static int dp83td510_config_intr(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83td510.c-534-\tif (phydev-\u003einterrupts == PHY_INTERRUPT_ENABLED) {\ndrivers/net/phy/dp83td510.c:535:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/dp83td510.c-536-\t\t\t\t DP83TD510E_INTERRUPT_REG_1,\n--\ndrivers/net/phy/dp83td510.c-546-\t} else {\ndrivers/net/phy/dp83td510.c:547:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/dp83td510.c-548-\t\t\t\t DP83TD510E_INTERRUPT_REG_1, 0x0);\n--\ndrivers/net/phy/dp83td510.c=684=static int dp83td510_cable_test_start(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83td510.c-738-\ndrivers/net/phy/dp83td510.c:739:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TD510E_TDR_CFG2,\ndrivers/net/phy/dp83td510.c-740-\t\t\t FIELD_PREP(DP83TD510E_TDR_END_TAP_INDEX_1,\n--\ndrivers/net/phy/dp83td510.c-746-\ndrivers/net/phy/dp83td510.c:747:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TD510E_TDR_FAULT_CFG1,\ndrivers/net/phy/dp83td510.c-748-\t\t\t FIELD_PREP(DP83TD510E_TDR_FLT_LOC_OFFSET_1,\n--\ndrivers/net/phy/dp83td510.c-757-\t */\ndrivers/net/phy/dp83td510.c:758:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TD510E_UNKN_030E,\ndrivers/net/phy/dp83td510.c-759-\t\t\t DP83TD510E_030E_VAL);\n--\ndrivers/net/phy/dp83td510.c-762-\ndrivers/net/phy/dp83td510.c:763:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TD510E_TDR_CFG3,\ndrivers/net/phy/dp83td510.c-764-\t\t\t DP83TD510E_TDR_TX_DURATION_US_DEF);\n--\ndrivers/net/phy/dp83tg720.c=324=static int dp83tg720_cable_test_start(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83tg720.c-340-\ndrivers/net/phy/dp83tg720.c:341:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TG720S_TDR_CFG2,\ndrivers/net/phy/dp83tg720.c-342-\t\t\t 0xa008);\n--\ndrivers/net/phy/dp83tg720.c-345-\ndrivers/net/phy/dp83tg720.c:346:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TG720S_TDR_CFG3,\ndrivers/net/phy/dp83tg720.c-347-\t\t\t 0x0928);\n--\ndrivers/net/phy/dp83tg720.c-350-\ndrivers/net/phy/dp83tg720.c:351:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TG720S_TDR_CFG4,\ndrivers/net/phy/dp83tg720.c-352-\t\t\t 0x0004);\n--\ndrivers/net/phy/dp83tg720.c-355-\ndrivers/net/phy/dp83tg720.c:356:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TG720S_UNKNOWN_0405,\ndrivers/net/phy/dp83tg720.c-357-\t\t\t 0x6400);\n--\ndrivers/net/phy/dp83tg720.c-360-\ndrivers/net/phy/dp83tg720.c:361:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TG720S_UNKNOWN_083F,\ndrivers/net/phy/dp83tg720.c-362-\t\t\t 0x3003);\n--\ndrivers/net/phy/dp83tg720.c=558=static int dp83tg720_config_init(struct phy_device *phydev)\n--\ndrivers/net/phy/dp83tg720.c-575-\t */\ndrivers/net/phy/dp83tg720.c:576:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, DP83TG720S_LPS_CFG3,\ndrivers/net/phy/dp83tg720.c-577-\t\t\t DP83TG720S_LPS_CFG3_PWR_MODE_0);\n--\ndrivers/net/phy/intel-xway.c=245=static int xway_gphy_init_leds(struct phy_device *phydev)\n--\ndrivers/net/phy/intel-xway.c-259-\ndrivers/net/phy/intel-xway.c:260:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LEDCH,\ndrivers/net/phy/intel-xway.c-261-\t\t XWAY_MMD_LEDCH_NACS_NONE |\n--\ndrivers/net/phy/intel-xway.c-263-\t\t XWAY_MMD_LEDCH_FBF_F16HZ);\ndrivers/net/phy/intel-xway.c:264:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LEDCL,\ndrivers/net/phy/intel-xway.c-265-\t\t XWAY_MMD_LEDCH_CBLINK_NONE |\n--\ndrivers/net/phy/intel-xway.c-276-\t\tXWAY_MMD_LEDxL_BLINKS_NONE;\ndrivers/net/phy/intel-xway.c:277:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED0H, ledxh);\ndrivers/net/phy/intel-xway.c:278:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED0L, ledxl);\ndrivers/net/phy/intel-xway.c:279:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED1H, ledxh);\ndrivers/net/phy/intel-xway.c:280:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED1L, ledxl);\ndrivers/net/phy/intel-xway.c:281:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED2H, ledxh);\ndrivers/net/phy/intel-xway.c:282:\tphy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LED2L, ledxl);\ndrivers/net/phy/intel-xway.c-283-\n--\ndrivers/net/phy/intel-xway.c=393=static int xway_gphy_led_brightness_set(struct phy_device *phydev,\n--\ndrivers/net/phy/intel-xway.c-410-\tif (value == LED_OFF) {\ndrivers/net/phy/intel-xway.c:411:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LEDxH(index), 0);\ndrivers/net/phy/intel-xway.c-412-\t\tif (ret)\n--\ndrivers/net/phy/intel-xway.c-414-\ndrivers/net/phy/intel-xway.c:415:\t\treturn phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LEDxL(index), 0);\ndrivers/net/phy/intel-xway.c-416-\t} else {\n--\n\n"
} |
| 41/2 | 2026/08/06 16:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 42363 output: 35 thoughts: 54 Thoughts: Here's my take on those thoughts: **Analyzing `phy_write_mmd` Usage** Okay, so `phy_write_mmd` is a function that's clearly being utilized across a significant portion of the PHY driver codebase. That's immediately interesting, because a function this broadly used merits careful scrutiny. But wait, did I just see that `phy_ethtool_set_eee` is calling `phy_write_mmd`? That's a good starting point. I need to understand how Energy Efficient Ethernet (EEE) interacts with the MMD register writes, as this interaction may be important for debug. Let's dig into `phy_ethtool_set_eee` and see what's going on there. I need to understand this better. |
| 42/2 | 2026/08/06 16:25 | tool | grepper |
0mArgs:{
"Expression": "phy_ethtool_set_eee",
"PathPrefix": "drivers/net/phy/"
}Results: {
"Output": "drivers/net/phy/phy.c=1952=EXPORT_SYMBOL(phy_ethtool_get_eee);\n--\ndrivers/net/phy/phy.c-1954-/**\ndrivers/net/phy/phy.c:1955: * phy_ethtool_set_eee_noneg - Adjusts MAC LPI configuration without PHY\ndrivers/net/phy/phy.c-1956- *\t\t\t renegotiation\n--\ndrivers/net/phy/phy.c-1967- */\ndrivers/net/phy/phy.c:1968:static void phy_ethtool_set_eee_noneg(struct phy_device *phydev,\ndrivers/net/phy/phy.c-1969-\t\t\t\t const struct eee_config *old_cfg)\n--\ndrivers/net/phy/phy.c-1989-/**\ndrivers/net/phy/phy.c:1990: * phy_ethtool_set_eee - set EEE supported and status\ndrivers/net/phy/phy.c-1991- * @phydev: target phy_device struct\n--\ndrivers/net/phy/phy.c-1995- */\ndrivers/net/phy/phy.c:1996:int phy_ethtool_set_eee(struct phy_device *phydev, struct ethtool_keee *data)\ndrivers/net/phy/phy.c-1997-{\n--\ndrivers/net/phy/phy.c-2010-\tif (ret == 0)\ndrivers/net/phy/phy.c:2011:\t\tphy_ethtool_set_eee_noneg(phydev, \u0026old_cfg);\ndrivers/net/phy/phy.c-2012-\telse if (ret \u003c 0)\n--\ndrivers/net/phy/phy.c-2018-}\ndrivers/net/phy/phy.c:2019:EXPORT_SYMBOL(phy_ethtool_set_eee);\ndrivers/net/phy/phy.c-2020-\n--\ndrivers/net/phy/phylink.c=3322=int phylink_ethtool_set_eee(struct phylink *pl, struct ethtool_keee *eee)\n--\ndrivers/net/phy/phylink.c-3342-\t\t\t\t pl-\u003esupported_lpi);\ndrivers/net/phy/phylink.c:3343:\t\tret = phy_ethtool_set_eee(pl-\u003ephydev, eee);\ndrivers/net/phy/phylink.c-3344-\t\tif (ret == 0)\n"
} |
| 43/2 | 2026/08/06 16:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 43275 output: 38 thoughts: 21 Thoughts: Here's my take on those thoughts, tailored for an expert audience: **Diving into phy_ethtool_set_eee** Okay, so I'm thinking about `phy_ethtool_set_eee` in `phy.c`. Straight away, I'm envisioning the potential implications. It's the EEE (Energy Efficient Ethernet) setting function, meaning it's how we're controlling the power-saving behavior of the PHY. I need to refresh my memory on the specific PHY registers involved in EEE negotiation and operation. I'm probably going to start by tracing the function's call flow to see how the arguments are handled and if there's any critical validation. I'm keen to understand how it interfaces with the generic PHY driver framework and any vendor-specific extensions that might be in play. I'll be looking for how it sets the Auto-MDIX mode alongside the EEE configuration, since the combination of those two settings is pretty important. I expect to see the function interacting with the MMD registers, as that's often where the EEE settings live. I'll need to check how it handles the potential for retries or error handling during the register writes. I'm also curious if it dynamically adjusts any other settings based on the EEE configuration, like link speed or duplex. It's also worth looking for how it handles different PHY revisions or vendor-specific EEE features. I'll have to see if the driver correctly handles situations where the PHY might not support EEE, and also how it reports the setting back to the user space. Basically, I want to understand the full picture, from user-space request to PHY register writes, so I can ensure it's doing the right thing, and efficiently too. |
| 44/2 | 2026/08/06 16:25 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/phy.c",
"FirstLine": 1996,
"LineCount": 30
}Results: {
"Contents": "1996:\tint phy_ethtool_set_eee(struct phy_device *phydev, struct ethtool_keee *data)\n1997:\t{\n1998:\t\tstruct eee_config old_cfg;\n1999:\t\tint ret;\n2000:\t\n2001:\t\tif (!phydev-\u003edrv)\n2002:\t\t\treturn -EIO;\n2003:\t\n2004:\t\tmutex_lock(\u0026phydev-\u003elock);\n2005:\t\n2006:\t\told_cfg = phydev-\u003eeee_cfg;\n2007:\t\teee_to_eeecfg(\u0026phydev-\u003eeee_cfg, data);\n2008:\t\n2009:\t\tret = genphy_c45_ethtool_set_eee(phydev, data);\n2010:\t\tif (ret == 0)\n2011:\t\t\tphy_ethtool_set_eee_noneg(phydev, \u0026old_cfg);\n2012:\t\telse if (ret \u003c 0)\n2013:\t\t\tphydev-\u003eeee_cfg = old_cfg;\n2014:\t\n2015:\t\tmutex_unlock(\u0026phydev-\u003elock);\n2016:\t\n2017:\t\treturn ret \u003c 0 ? ret : 0;\n2018:\t}\n2019:\tEXPORT_SYMBOL(phy_ethtool_set_eee);\n2020:\t\n2021:\t/**\n2022:\t * phy_ethtool_set_wol - Configure Wake On LAN\n2023:\t *\n2024:\t * @phydev: target phy_device struct\n2025:\t * @wol: Configuration requested\n"
} |
| 45/2 | 2026/08/06 16:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 44161 output: 40 thoughts: 27 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience: **Analyzing the `genphy_c45_ethtool_set_eee` Function** Okay, so `genphy_c45_ethtool_set_eee` has been invoked. My first instinct is to immediately dig in and understand its purpose. Given the name, I'm betting it relates to setting Energy Efficient Ethernet (EEE) parameters, and the "genphy_c45" prefix suggests it's dealing with a generic PHY, specifically one that's managed through the Clause 45 (or MDIO) interface, likely via a standardized register set. I need to quickly determine: * What specific EEE parameters is it designed to modify? Is it controlling the advertised capabilities, the operational settings, or something else entirely? * How does it interact with the underlying hardware? Does it directly write to the PHY registers, or does it utilize some abstraction layer or helper functions? * What's the overall context? Is this called during driver initialization, link configuration, or as a response to an `ethtool` command? Understanding the call stack is crucial. * Are there any assumptions about the PHY model or capabilities? Does it check for the presence of certain registers or features? I need to look for any potential for hardware-specific handling. * What error handling is present? Are there checks for invalid input or communication failures with the PHY? I'll start by tracing the function's execution path and carefully examine the register accesses. I'll need to correlate these with the Clause 45 specifications to determine the exact impact on the PHY's EEE behavior. Any use of masks or bitfields will be of particular interest. I want to see how it handles things like the LPI (Low Power Idle) timers and other EEE-related configurations. Basically, I need to verify that it's doing the right thing, in the right way, and under the right conditions, without unintentionally breaking anything else. |
| 46/2 | 2026/08/06 16:25 | tool | grepper |
0mArgs:{
"Expression": "genphy_c45_ethtool_set_eee",
"PathPrefix": "drivers/net/phy/"
}Results: {
"Output": "drivers/net/phy/phy-c45.c=1657=EXPORT_SYMBOL(genphy_c45_ethtool_get_eee);\n--\ndrivers/net/phy/phy-c45.c-1659-/**\ndrivers/net/phy/phy-c45.c:1660: * genphy_c45_ethtool_set_eee - set EEE supported and status\ndrivers/net/phy/phy-c45.c-1661- * @phydev: target phy_device struct\n--\ndrivers/net/phy/phy-c45.c-1671- */\ndrivers/net/phy/phy-c45.c:1672:int genphy_c45_ethtool_set_eee(struct phy_device *phydev,\ndrivers/net/phy/phy-c45.c-1673-\t\t\t struct ethtool_keee *data)\n--\ndrivers/net/phy/phy-c45.c-1708-}\ndrivers/net/phy/phy-c45.c:1709:EXPORT_SYMBOL(genphy_c45_ethtool_set_eee);\ndrivers/net/phy/phy-c45.c-1710-\n--\ndrivers/net/phy/phy.c=1996=int phy_ethtool_set_eee(struct phy_device *phydev, struct ethtool_keee *data)\n--\ndrivers/net/phy/phy.c-2008-\ndrivers/net/phy/phy.c:2009:\tret = genphy_c45_ethtool_set_eee(phydev, data);\ndrivers/net/phy/phy.c-2010-\tif (ret == 0)\n"
} |
| 47/2 | 2026/08/06 16:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 45114 output: 42 thoughts: 20 Thoughts: Okay, let's dive into this `genphy_c45_ethtool_set_eee` function. **Analyzing genphy_c45_ethtool_set_eee** Right, so this function is clearly about setting Energy Efficient Ethernet (EEE) parameters for a generic PHY that's using the Clause 45 (C45) register interface. We're dealing with a common PHY, which means there's a good chance this function is called from a broader driver, so I need to understand its role within the larger picture. First, I need to see if it handles the configuration of EEE based on what's passed in from ethtool. I need to understand what's required on the hardware side and how the driver translates the user's intention (enable, disable, specific settings) into actual register writes. I'll need to know whether it uses some sort of helper functions or structures to abstract the C45 register access, or if it has to directly manipulate the registers. I'll need to assess how it deals with potential errors, and what the flow is during initialization, and how it interacts with other PHY settings. Given that it's `genphy`, I'm assuming it's designed to be fairly generic, and I'd expect it to handle the bit-fiddling for the relevant C45 registers correctly, but I need to make sure that it deals with all the corner cases properly, especially if the device has specific requirements or limitations. I also want to see how the settings are verified to ensure that the set values work as expected. I need to determine if it handles any special cases for C45 PHYs or specific C45 versions. It's likely also looking at standard registers, so I have to be able to follow the flow and see how things get set up correctly. |
| 48/2 | 2026/08/06 16:26 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/phy-c45.c",
"FirstLine": 1672,
"LineCount": 40
}Results: {
"Contents": "1672:\tint genphy_c45_ethtool_set_eee(struct phy_device *phydev,\n1673:\t\t\t\t struct ethtool_keee *data)\n1674:\t{\n1675:\t\tint ret;\n1676:\t\n1677:\t\tif (data-\u003eeee_enabled) {\n1678:\t\t\tunsigned long *adv = data-\u003eadvertised;\n1679:\t\n1680:\t\t\tif (!linkmode_empty(adv)) {\n1681:\t\t\t\t__ETHTOOL_DECLARE_LINK_MODE_MASK(tmp);\n1682:\t\n1683:\t\t\t\tif (linkmode_andnot(tmp, adv, phydev-\u003esupported_eee)) {\n1684:\t\t\t\t\tphydev_warn(phydev, \"At least some EEE link modes are not supported.\\n\");\n1685:\t\t\t\t\treturn -EINVAL;\n1686:\t\t\t\t}\n1687:\t\n1688:\t\t\t\tlinkmode_andnot(phydev-\u003eadvertising_eee, adv,\n1689:\t\t\t\t\t\tphydev-\u003eeee_disabled_modes);\n1690:\t\t\t} else if (linkmode_empty(phydev-\u003eadvertising_eee)) {\n1691:\t\t\t\tphy_advertise_eee_all(phydev);\n1692:\t\t\t}\n1693:\t\t}\n1694:\t\n1695:\t\tret = genphy_c45_an_config_eee_aneg(phydev);\n1696:\t\tif (ret \u003e 0) {\n1697:\t\t\tret = phy_restart_aneg(phydev);\n1698:\t\t\tif (ret \u003c 0)\n1699:\t\t\t\treturn ret;\n1700:\t\n1701:\t\t\t/* explicitly return 1, otherwise (ret \u003e 0) value will be\n1702:\t\t\t * overwritten by phy_restart_aneg().\n1703:\t\t\t */\n1704:\t\t\treturn 1;\n1705:\t\t}\n1706:\t\n1707:\t\treturn ret;\n1708:\t}\n1709:\tEXPORT_SYMBOL(genphy_c45_ethtool_set_eee);\n1710:\t\n1711:\t/**\n"
} |
| 49/2 | 2026/08/06 16:26 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 46153 output: 41 thoughts: 25 Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person: **Analyzing the Function Call: `genphy_c45_an_config_eee_aneg`** Alright, so the code flow has reached a call to `genphy_c45_an_config_eee_aneg`. My initial thought is to dive right in and dissect this function. Given the naming convention, I'm already making some educated guesses, but let's confirm them. The `genphy_` prefix strongly suggests this is related to generic PHY (physical layer) operations. The "C45" part probably indicates this deals with Clause 45 registers, meaning this will be an MDIO based function. "AN" is a no brainer, meaning it's linked to auto-negotiation, and "EEE" points to Energy Efficient Ethernet. Lastly, the `aneg` suffix, well... that looks self-explanatory! So, the hypothesis is that this function will configure Energy Efficient Ethernet auto-negotiation, probably using the MDIO interface. My immediate next step is to examine the function's definition and implementation, maybe even the function's usage, to fully grasp its role within the wider PHY initialization sequence. This will hopefully clarify the specific registers being accessed, the negotiation process logic, and any potential dependencies it has with other parts of the driver. I expect to see register writes related to advertising EEE capabilities and maybe reading back the results of the auto-negotiation process. The goal is to fully understand how EEE is enabled and configured on this particular PHY. |
| 50/2 | 2026/08/06 16:26 | tool | grepper |
0mArgs:{
"Expression": "genphy_c45_an_config_eee_aneg",
"PathPrefix": "drivers/net/phy/"
}Results: {
"Output": "drivers/net/phy/bcm-phy-lib.c=1144=int bcm_config_lre_aneg(struct phy_device *phydev, bool changed)\n--\ndrivers/net/phy/bcm-phy-lib.c-1147-\ndrivers/net/phy/bcm-phy-lib.c:1148:\tif (genphy_c45_an_config_eee_aneg(phydev) \u003e 0)\ndrivers/net/phy/bcm-phy-lib.c-1149-\t\tchanged = true;\n--\ndrivers/net/phy/phy-c45.c=269=int genphy_c45_an_config_aneg(struct phy_device *phydev)\n--\ndrivers/net/phy/phy-c45.c-276-\ndrivers/net/phy/phy-c45.c:277:\tret = genphy_c45_an_config_eee_aneg(phydev);\ndrivers/net/phy/phy-c45.c-278-\tif (ret \u003c 0)\n--\ndrivers/net/phy/phy-c45.c=1048=EXPORT_SYMBOL_GPL(genphy_c45_read_eee_abilities);\n--\ndrivers/net/phy/phy-c45.c-1050-/**\ndrivers/net/phy/phy-c45.c:1051: * genphy_c45_an_config_eee_aneg - configure EEE advertisement\ndrivers/net/phy/phy-c45.c-1052- * @phydev: target phy_device struct\ndrivers/net/phy/phy-c45.c-1053- */\ndrivers/net/phy/phy-c45.c:1054:int genphy_c45_an_config_eee_aneg(struct phy_device *phydev)\ndrivers/net/phy/phy-c45.c-1055-{\n--\ndrivers/net/phy/phy-c45.c-1071-}\ndrivers/net/phy/phy-c45.c:1072:EXPORT_SYMBOL_GPL(genphy_c45_an_config_eee_aneg);\ndrivers/net/phy/phy-c45.c-1073-\n--\ndrivers/net/phy/phy-c45.c=1672=int genphy_c45_ethtool_set_eee(struct phy_device *phydev,\n--\ndrivers/net/phy/phy-c45.c-1694-\ndrivers/net/phy/phy-c45.c:1695:\tret = genphy_c45_an_config_eee_aneg(phydev);\ndrivers/net/phy/phy-c45.c-1696-\tif (ret \u003e 0) {\n--\ndrivers/net/phy/phy_device.c=2309=int __genphy_config_aneg(struct phy_device *phydev, bool changed)\n--\ndrivers/net/phy/phy_device.c-2315-\ndrivers/net/phy/phy_device.c:2316:\terr = genphy_c45_an_config_eee_aneg(phydev);\ndrivers/net/phy/phy_device.c-2317-\tif (err \u003c 0)\n"
} |
| 51/2 | 2026/08/06 16:26 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 47420 output: 42 thoughts: 21 Thoughts: Okay, let's dive into this. Here's my take on `genphy_c45_an_config_eee_aneg`. **Diving into `genphy_c45_an_config_eee_aneg`** Alright, I see this is a function related to configuring and handling Energy Efficient Ethernet (EEE) and Auto-Negotiation (AN) using a C45 PHY interface. My immediate assumption is that this will involve manipulating specific registers within the PHY to enable, disable, and adjust EEE settings, likely in conjunction with AN states. I'm expecting to see logic for advertisement of EEE capabilities during AN, as well as the actual switching of the PHY into and out of EEE modes based on the link partner's responses. I'll need to pay close attention to the handling of different EEE flavors (if applicable, which I suspect it is), like LPI (Low Power Idle) and maybe other power-saving mechanisms. The C45 interface suggests this is a relatively modern PHY, likely with more advanced features and configuration options than an older, simpler interface. I'll be looking for robust error handling, as EEE can be sensitive to timing and misconfiguration. I'm also hoping for some clear state machine logic within this function, making it easier to follow the transitions between AN and EEE states. I'll be keeping an eye out for any potential race conditions and concurrency issues, especially if this function is used in a multi-threaded environment. Ultimately, the goal is to see how this implementation ensures optimal power savings while maintaining a reliable network connection. Let's see how it's done... |
| 52/2 | 2026/08/06 16:26 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/phy-c45.c",
"FirstLine": 1054,
"LineCount": 20
}Results: {
"Contents": "1054:\tint genphy_c45_an_config_eee_aneg(struct phy_device *phydev)\n1055:\t{\n1056:\t\t/* Writing MMD AN advertisements while autoneg is disabled has no\n1057:\t\t * effect on link-partner negotiation, but on some PHYs (e.g. the\n1058:\t\t * Broadcom BCM54213PE) the write itself disturbs the receive\n1059:\t\t * datapath. Skip it.\n1060:\t\t */\n1061:\t\tif (phydev-\u003eautoneg == AUTONEG_DISABLE)\n1062:\t\t\treturn 0;\n1063:\t\n1064:\t\tif (!phydev-\u003eeee_cfg.eee_enabled) {\n1065:\t\t\t__ETHTOOL_DECLARE_LINK_MODE_MASK(adv) = {};\n1066:\t\n1067:\t\t\treturn genphy_c45_write_eee_adv(phydev, adv);\n1068:\t\t}\n1069:\t\n1070:\t\treturn genphy_c45_write_eee_adv(phydev, phydev-\u003eadvertising_eee);\n1071:\t}\n1072:\tEXPORT_SYMBOL_GPL(genphy_c45_an_config_eee_aneg);\n1073:\t\n"
} |
| 53/2 | 2026/08/06 16:26 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 48184 output: 38 thoughts: 22 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience: **Analyzing the EEE Advertisement Write Call** Okay, I see the code is calling `genphy_c45_write_eee_adv`. Right, I need to understand what's happening within that function call. My initial focus is on the `genphy` prefix. This suggests we're dealing with generic PHY functionality, specifically concerning the C45 interface. I'll need to remember the architectural context. I'm assuming it's handling the Energy Efficient Ethernet (EEE) advertisement register write operation. Let's delve into the specifics of what `genphy_c45_write_eee_adv` does. What parameters is it taking? What register addresses is it writing to, and what data is being written? I need to quickly determine if it’s correctly forming the EEE advertisement frame, ensuring the proper bit fields are set according to the standard and the desired configuration for this specific PHY. Is there any register masking involved? I need to check for potential error handling and if it's returning any relevant status codes. Finally, I’ll need to cross-reference this with the relevant PHY datasheet to ensure compatibility. |
| 54/2 | 2026/08/06 16:26 | tool | grepper |
0mArgs:{
"Expression": "genphy_c45_write_eee_adv",
"PathPrefix": "drivers/net/phy/"
}Results: {
"Output": "drivers/net/phy/phy-c45.c=791=EXPORT_SYMBOL_GPL(genphy_c45_read_mdix);\n--\ndrivers/net/phy/phy-c45.c-793-/**\ndrivers/net/phy/phy-c45.c:794: * genphy_c45_write_eee_adv - write advertised EEE link modes\ndrivers/net/phy/phy-c45.c-795- * @phydev: target phy_device struct\n--\ndrivers/net/phy/phy-c45.c-797- */\ndrivers/net/phy/phy-c45.c:798:static int genphy_c45_write_eee_adv(struct phy_device *phydev,\ndrivers/net/phy/phy-c45.c-799-\t\t\t\t unsigned long *adv)\n--\ndrivers/net/phy/phy-c45.c=1054=int genphy_c45_an_config_eee_aneg(struct phy_device *phydev)\n--\ndrivers/net/phy/phy-c45.c-1066-\ndrivers/net/phy/phy-c45.c:1067:\t\treturn genphy_c45_write_eee_adv(phydev, adv);\ndrivers/net/phy/phy-c45.c-1068-\t}\ndrivers/net/phy/phy-c45.c-1069-\ndrivers/net/phy/phy-c45.c:1070:\treturn genphy_c45_write_eee_adv(phydev, phydev-\u003eadvertising_eee);\ndrivers/net/phy/phy-c45.c-1071-}\n"
} |
| 55/2 | 2026/08/06 16:26 | llm | patch-evaluator |
1mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 48946 output: 41 thoughts: 18 Thoughts: Okay, here's my interpretation of what's going through my mind as I approach this `genphy_c45_write_eee_adv` function. **Analyzing genphy_c45_write_eee_adv** Alright, time to dive into this `genphy_c45_write_eee_adv` function. My initial thought process revolves around a few key questions: What's the context? What's the larger system this function fits into? I need to understand this to have any chance of grasping its inner workings effectively. I'm assuming, given the name, it has something to do with the generation of PHY control signals, specifically concerning EEE (Energy Efficient Ethernet) advertisement over a C45 interface, likely to a PHY device. Next, I'll be looking for how it interacts with other PHY functions. I'll need to identify any dependencies on other functions, like those related to register access (probably using an MDIO interface via the C45 clause). I'll need to understand if this write is part of a larger initialization sequence, a dynamic configuration procedure, or perhaps a response to some external event or status change. I'm expecting to see things like register address definitions, bitfield manipulations, and perhaps some error checking. The way the EEE advertisement is structured in the C45 space is something I'll want to quickly understand – does it use a defined set of registers, or are we working with vendor-specific configurations? I'm hoping it's straightforward but I've seen enough vendor quirks. I’ll be paying close attention to any error conditions and how they're handled. If it is error handling, are there any retry mechanisms, or does it simply return an error code? A well-written PHY driver usually includes some resilience. Finally, a quick glance at the surrounding code might be needed to see if it makes calls to any logging or debug facilities. This can be critical to understand in a debugging situation. Right now, I will start to dissect the code and build a mental model of how this function interacts with the hardware, the software driver, and the rest of the network stack. I'm ready to get started. |
| 56/2 | 2026/08/06 16:28 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/phy-c45.c",
"FirstLine": 798,
"LineCount": 20
}Results: {
"Contents": " 798:\tstatic int genphy_c45_write_eee_adv(struct phy_device *phydev,\n 799:\t\t\t\t\t unsigned long *adv)\n 800:\t{\n 801:\t\tint val, changed = 0;\n 802:\t\n 803:\t\tif (linkmode_intersects(phydev-\u003esupported_eee, PHY_EEE_CAP1_FEATURES)) {\n 804:\t\t\tval = linkmode_to_mii_eee_cap1_t(adv);\n 805:\t\n 806:\t\t\t/* IEEE 802.3-2018 45.2.7.13 EEE advertisement 1\n 807:\t\t\t * (Register 7.60)\n 808:\t\t\t */\n 809:\t\t\tval = phy_modify_mmd_changed(phydev, MDIO_MMD_AN,\n 810:\t\t\t\t\t\t MDIO_AN_EEE_ADV,\n 811:\t\t\t\t\t\t MDIO_EEE_100TX | MDIO_EEE_1000T |\n 812:\t\t\t\t\t\t MDIO_EEE_10GT | MDIO_EEE_1000KX |\n 813:\t\t\t\t\t\t MDIO_EEE_10GKX4 | MDIO_EEE_10GKR,\n 814:\t\t\t\t\t\t val);\n 815:\t\t\tif (val \u003c 0)\n 816:\t\t\t\treturn val;\n 817:\t\t\tif (val \u003e 0)\n"
} |
| 57/2 | 2026/08/06 16:28 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 49856 output: 40 thoughts: 377 Thoughts: **Analyzing the PHY Driver Patch** Okay, let's break this down. My initial thought process went like this: the code path involves `phy_modify_mmd_changed`, which is a wrapper calling both `phy_read_mmd` and `phy_write_mmd`. The `phy_write_mmd` function then ultimately calls `phydev->drv->write_mmd`. So, logically, `rtlgen_write_mmd` is definitely a function that's being invoked somewhere down the line, as it is related to this phy driver. Now, the patch itself. I see a conditional block: When `devnum` is `MDIO_MMD_VEND2`, the patch calls `rtlgen_write_vend2` which is the correct behavior. Now, let's look at the "else if" statement. The crucial change is here, within the `MDIO_MMD_AN` and `MDIO_AN_EEE_ADV` condition. The original code was passing `regnum` (which is `MDIO_AN_EEE_ADV`, or 60 IIRC) as the second argument, and `RTL_MDIO_AN_EEE_ADV` (a constant value) as the third argument to `rtlgen_write_vend2`. However, `rtlgen_write_vend2` clearly expects `regnum` and `val` as its second and third argument. Therefore, the old code was mistakenly writing the constant `RTL_MDIO_AN_EEE_ADV` to the register address `MDIO_AN_EEE_ADV` (60), which doesn't seem right. The patch now swaps these two arguments, passing `val` as the second argument and `val` as the third argument to the function. This is more in line with what I'd expect. Now it's writing `val` (the value we want to set) to `RTL_MDIO_AN_EEE_ADV`. That's a vendor-specific register, likely related to EEE (Energy Efficient Ethernet) advertisement. Now, let me just double-check the value of `RTL_MDIO_AN_EEE_ADV` to confirm my suspicion... |
| 58/2 | 2026/08/06 16:28 | tool | grepper |
0mArgs:{
"Expression": "RTL_MDIO_AN_EEE_ADV",
"PathPrefix": "drivers/net/phy/realtek/"
}Results: {
"Output": "drivers/net/phy/realtek/realtek_main.c-243-#define\tRTL_MDIO_PCS_EEE_ABLE\t\t\t0xa5c4\ndrivers/net/phy/realtek/realtek_main.c:244:#define\tRTL_MDIO_AN_EEE_ADV\t\t\t0xa5d0\ndrivers/net/phy/realtek/realtek_main.c-245-#define\tRTL_MDIO_AN_EEE_LPABLE\t\t\t0xa5d2\n--\ndrivers/net/phy/realtek/realtek_main.c-249-#define\tRTL_MDIO_AN_EEE_LPABLE2\t\t\t0xa6d0\ndrivers/net/phy/realtek/realtek_main.c:250:#define\tRTL_MDIO_AN_EEE_ADV2\t\t\t0xa6d4\ndrivers/net/phy/realtek/realtek_main.c-251-#define\tRTL_MDIO_PCS_EEE_ABLE2\t\t\t0xa6ec\n--\ndrivers/net/phy/realtek/realtek_main.c=1745=static int rtlgen_read_mmd(struct phy_device *phydev, int devnum, u16 regnum)\n--\ndrivers/net/phy/realtek/realtek_main.c-1753-\telse if (devnum == MDIO_MMD_AN \u0026\u0026 regnum == MDIO_AN_EEE_ADV)\ndrivers/net/phy/realtek/realtek_main.c:1754:\t\tret = rtlgen_read_vend2(phydev, RTL_MDIO_AN_EEE_ADV);\ndrivers/net/phy/realtek/realtek_main.c-1755-\telse if (devnum == MDIO_MMD_AN \u0026\u0026 regnum == MDIO_AN_EEE_LPABLE)\n--\ndrivers/net/phy/realtek/realtek_main.c=1763=static int rtlgen_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,\n--\ndrivers/net/phy/realtek/realtek_main.c-1770-\telse if (devnum == MDIO_MMD_AN \u0026\u0026 regnum == MDIO_AN_EEE_ADV)\ndrivers/net/phy/realtek/realtek_main.c:1771:\t\tret = rtlgen_write_vend2(phydev, RTL_MDIO_AN_EEE_ADV, val);\ndrivers/net/phy/realtek/realtek_main.c-1772-\telse\n--\ndrivers/net/phy/realtek/realtek_main.c=1778=static int rtl822x_read_mmd(struct phy_device *phydev, int devnum, u16 regnum)\n--\ndrivers/net/phy/realtek/realtek_main.c-1787-\telse if (devnum == MDIO_MMD_AN \u0026\u0026 regnum == MDIO_AN_EEE_ADV2)\ndrivers/net/phy/realtek/realtek_main.c:1788:\t\tret = rtlgen_read_vend2(phydev, RTL_MDIO_AN_EEE_ADV2);\ndrivers/net/phy/realtek/realtek_main.c-1789-\telse if (devnum == MDIO_MMD_AN \u0026\u0026 regnum == MDIO_AN_EEE_LPABLE2)\n--\ndrivers/net/phy/realtek/realtek_main.c=1795=static int rtl822x_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,\n--\ndrivers/net/phy/realtek/realtek_main.c-1803-\tif (devnum == MDIO_MMD_AN \u0026\u0026 regnum == MDIO_AN_EEE_ADV2)\ndrivers/net/phy/realtek/realtek_main.c:1804:\t\tret = rtlgen_write_vend2(phydev, RTL_MDIO_AN_EEE_ADV2, val);\ndrivers/net/phy/realtek/realtek_main.c-1805-\n"
} |
| 59/2 | 2026/08/06 16:28 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 51769 output: 44 thoughts: 682 Thoughts: **Analyzing a Functional Change in the Realtek PHY Driver** Okay, so I'm looking at this Realtek PHY driver change. The crux of it seems to be related to writing a specific value, `0xa5d0`, to a register. Previously, the code was explicitly writing this value to register 60 (`MDIO_AN_EEE_ADV`). Now, however, the new code is writing `val` to register `0xa5d0` directly. This is a pretty significant functional change – it's no longer a hardcoded value. This change is exposed to userspace. I can get to it through the `SIOCSMIIREG` ioctl if I'm using C45 MDIO access to write to `MDIO_MMD_AN` and `MDIO_AN_EEE_ADV`. Or, I can reach it through `ETHTOOL_SEEE`, which then calls a whole chain of functions: `phy_ethtool_set_eee` -> `genphy_c45_ethtool_set_eee` -> `genphy_c45_an_config_eee_aneg` -> `genphy_c45_write_eee_adv` -> `phy_modify_mmd_changed` -> `phy_write_mmd` -> `rtlgen_write_mmd`. The big question now is, is this worth fuzzing? Absolutely, yes! It's a functional change within a driver, and that always raises a flag. Can I trigger this in QEMU? Syzkaller has descriptions for `SIOCSMIIREG` and `ETHTOOL_SEEE` and can instantiate virtual network devices with PHYs! I could try using `tun`/`veth`, `vhci`, or even `netdevsim` to set it up. Hold on... wait, `netdevsim` doesn't use realtek PHYs, that's right. However, syzkaller *can* fuzz MDIO buses directly as long as it has a way to register a PHY. It looks like syzkaller can trigger `SIOCSMIIREG` on *any* netdev. If there's a PHY attached, it'll reach the PHY driver, which is exactly what I need. To hit `rtlgen_write_mmd` in particular, I absolutely need a Realtek PHY attached. Can I get a Realtek PHY attached with syzkaller? If I use `vhci` or something similar, or if a virtual device allows attaching arbitrary PHYs, I should be able to. I also need to make sure `CONFIG_REALTEK_PHY` is enabled. Right, so I need to check if `CONFIG_REALTEK_PHY` is the only config I need. Looks like it is - it's the module for Realtek PHYs. I need to make sure to check if there are any other dependencies. Looking again, `CONFIG_PHYLIB` is required, but that's usually enabled so I should be good. Let's check `FocusSymbols` to be sure. It looks like `rtlgen_write_mmd` is the function that's been modified, so that's the focus symbol. `rtl822x_write_mmd` calls `rtlgen_write_mmd`, so `rtlgen_write_mmd` is a good place to start. I should probably double-check `rtlgen_write_mmd` in `drivers/net/phy/realtek/realtek_main.c` just to be certain. |
| 60/2 | 2026/08/06 16:28 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/realtek/realtek_main.c",
"FirstLine": 1763,
"LineCount": 20
}Results: {
"Contents": "1763:\tstatic int rtlgen_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,\n1764:\t\t\t\t u16 val)\n1765:\t{\n1766:\t\tint ret;\n1767:\t\n1768:\t\tif (devnum == MDIO_MMD_VEND2)\n1769:\t\t\tret = rtlgen_write_vend2(phydev, regnum, val);\n1770:\t\telse if (devnum == MDIO_MMD_AN \u0026\u0026 regnum == MDIO_AN_EEE_ADV)\n1771:\t\t\tret = rtlgen_write_vend2(phydev, RTL_MDIO_AN_EEE_ADV, val);\n1772:\t\telse\n1773:\t\t\tret = -EOPNOTSUPP;\n1774:\t\n1775:\t\treturn ret;\n1776:\t}\n1777:\t\n1778:\tstatic int rtl822x_read_mmd(struct phy_device *phydev, int devnum, u16 regnum)\n1779:\t{\n1780:\t\tint ret = rtlgen_read_mmd(phydev, devnum, regnum);\n1781:\t\n1782:\t\tif (ret != -EOPNOTSUPP)\n"
} |
| 61/2 | 2026/08/06 16:28 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 53620 output: 36 thoughts: 171 Thoughts: **Analyzing the `rtlgen_write_mmd` Function for Fuzzing and Symbol Visibility** Okay, so I'm looking at this `rtlgen_write_mmd` function. It's marked as `static`, which initially makes me think fuzzing might be tricky. However, I realize that syzkaller *can* actually reach it through `phy_write_mmd`, which is an exported symbol. That's good to know. Now, considering `FocusSymbols`, I have to make sure `rtlgen_write_mmd` is explicitly provided, especially if it's not inlined. And I think that's unlikely; it's used as a function pointer in `realtek_drvs`: ```c .write_mmd = rtlgen_write_mmd, ``` Given it's used as a function pointer, there's no way the compiler can inline it. That confirms it, `rtlgen_write_mmd` *is* a valid symbol that should be visible. Let's not stop there, though. I should check if there are any other functions in this family. Aha, `rtlgen_write_vend2` is called. That sounds like another interesting one to look at and see if it's fuzzable and/or if it needs special attention for symbol visibility as well. Let me investigate `rtlgen_write_vend2`. |
| 62/2 | 2026/08/06 16:28 | tool | grepper |
0mArgs:{
"Expression": "rtlgen_write_vend2",
"PathPrefix": "drivers/net/phy/realtek/"
}Results: {
"Output": "drivers/net/phy/realtek/realtek_main.c=1734=static int rtlgen_read_vend2(struct phy_device *phydev, int regnum)\n--\ndrivers/net/phy/realtek/realtek_main.c-1738-\ndrivers/net/phy/realtek/realtek_main.c:1739:static int rtlgen_write_vend2(struct phy_device *phydev, int regnum, u16 val)\ndrivers/net/phy/realtek/realtek_main.c-1740-{\n--\ndrivers/net/phy/realtek/realtek_main.c=1763=static int rtlgen_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,\n--\ndrivers/net/phy/realtek/realtek_main.c-1768-\tif (devnum == MDIO_MMD_VEND2)\ndrivers/net/phy/realtek/realtek_main.c:1769:\t\tret = rtlgen_write_vend2(phydev, regnum, val);\ndrivers/net/phy/realtek/realtek_main.c-1770-\telse if (devnum == MDIO_MMD_AN \u0026\u0026 regnum == MDIO_AN_EEE_ADV)\ndrivers/net/phy/realtek/realtek_main.c:1771:\t\tret = rtlgen_write_vend2(phydev, RTL_MDIO_AN_EEE_ADV, val);\ndrivers/net/phy/realtek/realtek_main.c-1772-\telse\n--\ndrivers/net/phy/realtek/realtek_main.c=1795=static int rtl822x_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,\n--\ndrivers/net/phy/realtek/realtek_main.c-1803-\tif (devnum == MDIO_MMD_AN \u0026\u0026 regnum == MDIO_AN_EEE_ADV2)\ndrivers/net/phy/realtek/realtek_main.c:1804:\t\tret = rtlgen_write_vend2(phydev, RTL_MDIO_AN_EEE_ADV2, val);\ndrivers/net/phy/realtek/realtek_main.c-1805-\n"
} |
| 63/2 | 2026/08/06 16:28 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 54716 output: 32 thoughts: 106 Thoughts: **Focusing on the Realtek PHY Driver** Okay, so `rtlgen_write_vend2` is also declared static, making inlining a real possibility. That throws a wrench in the works. Better to target `rtlgen_write_mmd` then; it's less likely to be optimized away and more clearly represents the core of what I'm looking for. Now, let's see what other configurations might be relevant. `CONFIG_REALTEK_PHY` is the big one, of course. But are there any dependencies or related configurations I need to consider? Right, `CONFIG_PHYLIB` is *required* by `CONFIG_REALTEK_PHY`, that seems important. Time to revisit `drivers/net/phy/Kconfig` again to make sure I haven't missed anything. |
| 64/2 | 2026/08/06 16:28 | tool | grepper |
0mArgs:{
"Expression": "config REALTEK_PHY",
"PathPrefix": "drivers/net/phy/"
}Results: {
"Output": "drivers/net/phy/realtek/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/net/phy/realtek/Kconfig:2:config REALTEK_PHY\ndrivers/net/phy/realtek/Kconfig-3-\ttristate \"Realtek PHYs\"\n--\ndrivers/net/phy/realtek/Kconfig=8=if REALTEK_PHY\ndrivers/net/phy/realtek/Kconfig-9-\ndrivers/net/phy/realtek/Kconfig:10:config REALTEK_PHY_HWMON\ndrivers/net/phy/realtek/Kconfig-11-\tbool \"HWMON support for Realtek PHYs\"\n"
} |
| 65/2 | 2026/08/06 16:28 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 55208 output: 44 thoughts: 83 Thoughts: Okay, let's break this down. **Initial Assessment and Verification of Control Flow** Right, so we're focusing on this `REALTEK_PHY` driver or module, specifically. It looks like it's the only one in the running. Now, before I jump to any conclusions, I need to trace this control flow properly. I need to make sure I understand the relationships between these functions. Hang on, is `rtlgen_write_mmd` actually called from `rtl822x_write_mmd`? Let's check it, quickly. Aha! Yes, good. `rtl822x_write_mmd` does indeed call `rtlgen_write_mmd`. Okay, that's crucial. Now, since I've confirmed that relationship, I'm going to turn my attention to scrutinizing `rtl822x_write_mmd` itself. That function is where the action is starting. I'll need to see precisely what's happening there to understand how it interfaces with the lower level. |
| 66/2 | 2026/08/06 16:28 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/realtek/realtek_main.c",
"FirstLine": 1795,
"LineCount": 20
}Results: {
"Contents": "1795:\tstatic int rtl822x_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,\n1796:\t\t\t\t u16 val)\n1797:\t{\n1798:\t\tint ret = rtlgen_write_mmd(phydev, devnum, regnum, val);\n1799:\t\n1800:\t\tif (ret != -EOPNOTSUPP)\n1801:\t\t\treturn ret;\n1802:\t\n1803:\t\tif (devnum == MDIO_MMD_AN \u0026\u0026 regnum == MDIO_AN_EEE_ADV2)\n1804:\t\t\tret = rtlgen_write_vend2(phydev, RTL_MDIO_AN_EEE_ADV2, val);\n1805:\t\n1806:\t\treturn ret;\n1807:\t}\n1808:\t\n1809:\tstatic int rtl822x_probe(struct phy_device *phydev)\n1810:\t{\n1811:\t\tif (IS_ENABLED(CONFIG_REALTEK_PHY_HWMON) \u0026\u0026\n1812:\t\t phydev-\u003ephy_id != RTL_GENERIC_PHYID)\n1813:\t\t\treturn rtl822x_hwmon_init(phydev);\n1814:\t\n"
} |
| 67/2 | 2026/08/06 16:28 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 55915 output: 39 thoughts: 60 Thoughts: Okay, here's my take on those thoughts, framed as my own mental process: **Diving into PHY Driver Analysis** Alright, I need to zoom in on how these Realtek PHYs are being configured, so `rtl822x_write_mmd` looks like a key function to understand. It's calling to me as a potential focus symbol. It's been brought up multiple times as a potential entry point for this task. Now, to get a handle on the broader picture, I should probably check within `realtek_drvs` to see the relevant PHYs. I want to identify which specific drivers are leveraging either `rtlgen_write_mmd` or, more specifically, `rtl822x_write_mmd`. The aim is to map the function to a module. I am hoping to get more context and use `rtl822x_write_mmd` as a starting point. This should give me a solid base for tracing the control flow and understanding the register access patterns in these Realtek PHY implementations. |
| 68/2 | 2026/08/06 16:28 | tool | grepper |
0mArgs:{
"Expression": "write_mmd",
"PathPrefix": "drivers/net/phy/realtek/realtek_main.c"
}Results: {
"Output": "drivers/net/phy/realtek/realtek_main.c=388=static int rtl8261x_probe(struct phy_device *phydev)\n--\ndrivers/net/phy/realtek/realtek_main.c-399-\ndrivers/net/phy/realtek/realtek_main.c:400:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, RTL8261X_EXT_ADDR_REG,\ndrivers/net/phy/realtek/realtek_main.c-401-\t\t\t RTL_8261X_SUB_PHY_ID_ADDR);\n--\ndrivers/net/phy/realtek/realtek_main.c=620=static int rtl8261x_config_intr(struct phy_device *phydev)\n--\ndrivers/net/phy/realtek/realtek_main.c-628-\ndrivers/net/phy/realtek/realtek_main.c:629:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, RTL8221B_VND2_INER,\ndrivers/net/phy/realtek/realtek_main.c-630-\t\t\t\t RTL8261X_INT_MASK_DEFAULT);\n--\ndrivers/net/phy/realtek/realtek_main.c-633-\t} else {\ndrivers/net/phy/realtek/realtek_main.c:634:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, RTL8221B_VND2_INER, 0);\ndrivers/net/phy/realtek/realtek_main.c-635-\t\tif (ret \u003c 0)\n--\ndrivers/net/phy/realtek/realtek_main.c=1745=static int rtlgen_read_mmd(struct phy_device *phydev, int devnum, u16 regnum)\n--\ndrivers/net/phy/realtek/realtek_main.c-1762-\ndrivers/net/phy/realtek/realtek_main.c:1763:static int rtlgen_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,\ndrivers/net/phy/realtek/realtek_main.c-1764-\t\t\t u16 val)\n--\ndrivers/net/phy/realtek/realtek_main.c=1778=static int rtl822x_read_mmd(struct phy_device *phydev, int devnum, u16 regnum)\n--\ndrivers/net/phy/realtek/realtek_main.c-1794-\ndrivers/net/phy/realtek/realtek_main.c:1795:static int rtl822x_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,\ndrivers/net/phy/realtek/realtek_main.c-1796-\t\t\t u16 val)\ndrivers/net/phy/realtek/realtek_main.c-1797-{\ndrivers/net/phy/realtek/realtek_main.c:1798:\tint ret = rtlgen_write_mmd(phydev, devnum, regnum, val);\ndrivers/net/phy/realtek/realtek_main.c-1799-\n--\ndrivers/net/phy/realtek/realtek_main.c=1822=static int rtl822xb_read_mmd(struct phy_device *phydev, int devnum, u16 reg)\n--\ndrivers/net/phy/realtek/realtek_main.c-1860-\ndrivers/net/phy/realtek/realtek_main.c:1861:static int rtl822xb_write_mmd(struct phy_device *phydev, int devnum, u16 reg,\ndrivers/net/phy/realtek/realtek_main.c-1862-\t\t\t u16 val)\n--\ndrivers/net/phy/realtek/realtek_main.c=1941=static int rtl8226_patch_mdi_swap(struct phy_device *phydev, bool swap_enable)\n--\ndrivers/net/phy/realtek/realtek_main.c-1991-\ndrivers/net/phy/realtek/realtek_main.c:1992:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2, RTL8226_VND2_ADCCAL_OFFSET,\ndrivers/net/phy/realtek/realtek_main.c-1993-\t\t\t\t adccal_offset[3 - i]);\n--\ndrivers/net/phy/realtek/realtek_main.c=2039=static int rtl822x_set_serdes_option_mode(struct phy_device *phydev, bool gen1)\n--\ndrivers/net/phy/realtek/realtek_main.c-2075-\tif (!gen1) {\ndrivers/net/phy/realtek/realtek_main.c:2076:\t\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x75f3, 0);\ndrivers/net/phy/realtek/realtek_main.c-2077-\t\tif (ret \u003c 0)\n--\ndrivers/net/phy/realtek/realtek_main.c-2087-\ndrivers/net/phy/realtek/realtek_main.c:2088:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x6a04, 0x0503);\ndrivers/net/phy/realtek/realtek_main.c-2089-\tif (ret \u003c 0)\n--\ndrivers/net/phy/realtek/realtek_main.c-2091-\ndrivers/net/phy/realtek/realtek_main.c:2092:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x6f10, 0xd455);\ndrivers/net/phy/realtek/realtek_main.c-2093-\tif (ret \u003c 0)\n--\ndrivers/net/phy/realtek/realtek_main.c-2095-\ndrivers/net/phy/realtek/realtek_main.c:2096:\treturn phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x6f11, 0x8020);\ndrivers/net/phy/realtek/realtek_main.c-2097-}\n--\ndrivers/net/phy/realtek/realtek_main.c=2109=static int rtl822x_serdes_write(struct phy_device *phydev, u16 reg, u16 val)\n--\ndrivers/net/phy/realtek/realtek_main.c-2112-\ndrivers/net/phy/realtek/realtek_main.c:2113:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, RTL822X_VND1_SERDES_ADDR, reg);\ndrivers/net/phy/realtek/realtek_main.c-2114-\tif (ret \u003c 0)\n--\ndrivers/net/phy/realtek/realtek_main.c-2116-\ndrivers/net/phy/realtek/realtek_main.c:2117:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, RTL822X_VND1_SERDES_DATA, val);\ndrivers/net/phy/realtek/realtek_main.c-2118-\tif (ret \u003c 0)\n--\ndrivers/net/phy/realtek/realtek_main.c-2120-\ndrivers/net/phy/realtek/realtek_main.c:2121:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND1, RTL822X_VND1_SERDES_CMD,\ndrivers/net/phy/realtek/realtek_main.c-2122-\t\t\t RTL822X_VND1_SERDES_CMD_WRITE |\n--\ndrivers/net/phy/realtek/realtek_main.c=2369=static int rtl822xb_led_brightness_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/realtek/realtek_main.c-2377-\t/* clear HW LED setup */\ndrivers/net/phy/realtek/realtek_main.c:2378:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/realtek/realtek_main.c-2379-\t\t\t RTL822X_VND2_LED(index), 0);\n--\ndrivers/net/phy/realtek/realtek_main.c=2469=static int rtl822xb_led_hw_control_set(struct phy_device *phydev, u8 index,\n--\ndrivers/net/phy/realtek/realtek_main.c-2494-\ndrivers/net/phy/realtek/realtek_main.c:2495:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/realtek/realtek_main.c-2496-\t\t\t RTL822X_VND2_LED(index), val);\n--\ndrivers/net/phy/realtek/realtek_main.c=2541=static int rtl8224_sram_read(struct phy_device *phydev, u32 reg)\n--\ndrivers/net/phy/realtek/realtek_main.c-2544-\ndrivers/net/phy/realtek/realtek_main.c:2545:\tret = phy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/realtek/realtek_main.c-2546-\t\t\t RTL822X_VND2_C22_REG(RTL8224_MII_SRAM_ADDR),\n--\ndrivers/net/phy/realtek/realtek_main.c=2676=static int rtl8224_package_modify_mmd(struct phy_device *phydev, int devad,\n--\ndrivers/net/phy/realtek/realtek_main.c-2691-\ndrivers/net/phy/realtek/realtek_main.c:2692:\tret = __phy_package_write_mmd(phydev, 0, devad, regnum, val);\ndrivers/net/phy/realtek/realtek_main.c-2693-\n--\ndrivers/net/phy/realtek/realtek_main.c=3009=static int rtl8221b_config_intr(struct phy_device *phydev)\n--\ndrivers/net/phy/realtek/realtek_main.c-3017-\ndrivers/net/phy/realtek/realtek_main.c:3018:\t\terr = phy_write_mmd(phydev, MDIO_MMD_VEND2, RTL8221B_VND2_INER,\ndrivers/net/phy/realtek/realtek_main.c-3019-\t\t\t\t RTL8221B_VND2_INER_LINK_STATUS);\ndrivers/net/phy/realtek/realtek_main.c-3020-\t} else {\ndrivers/net/phy/realtek/realtek_main.c:3021:\t\terr = phy_write_mmd(phydev, MDIO_MMD_VEND2,\ndrivers/net/phy/realtek/realtek_main.c-3022-\t\t\t\t RTL8221B_VND2_INER, 0);\n--\ndrivers/net/phy/realtek/realtek_main.c=3086=static struct phy_driver realtek_drvs[] = {\n--\ndrivers/net/phy/realtek/realtek_main.c-3104-\t\t.read_mmd\t= genphy_read_mmd_unsupported,\ndrivers/net/phy/realtek/realtek_main.c:3105:\t\t.write_mmd\t= genphy_write_mmd_unsupported,\ndrivers/net/phy/realtek/realtek_main.c-3106-\t\t.suspend\t= genphy_suspend,\n--\ndrivers/net/phy/realtek/realtek_main.c-3114-\t\t.read_mmd\t= \u0026genphy_read_mmd_unsupported,\ndrivers/net/phy/realtek/realtek_main.c:3115:\t\t.write_mmd\t= \u0026genphy_write_mmd_unsupported,\ndrivers/net/phy/realtek/realtek_main.c-3116-\t\t.read_page\t= rtl821x_read_page,\n--\ndrivers/net/phy/realtek/realtek_main.c-3123-\t\t.read_mmd\t= \u0026genphy_read_mmd_unsupported,\ndrivers/net/phy/realtek/realtek_main.c:3124:\t\t.write_mmd\t= \u0026genphy_write_mmd_unsupported,\ndrivers/net/phy/realtek/realtek_main.c-3125-\t\t.suspend\t= rtl8211b_suspend,\n--\ndrivers/net/phy/realtek/realtek_main.c-3133-\t\t.read_mmd\t= \u0026genphy_read_mmd_unsupported,\ndrivers/net/phy/realtek/realtek_main.c:3134:\t\t.write_mmd\t= \u0026genphy_write_mmd_unsupported,\ndrivers/net/phy/realtek/realtek_main.c-3135-\t\t.read_page\t= rtl821x_read_page,\n--\ndrivers/net/phy/realtek/realtek_main.c-3203-\t\t.read_mmd\t= rtlgen_read_mmd,\ndrivers/net/phy/realtek/realtek_main.c:3204:\t\t.write_mmd\t= rtlgen_write_mmd,\ndrivers/net/phy/realtek/realtek_main.c-3205-\t}, {\n--\ndrivers/net/phy/realtek/realtek_main.c-3215-\t\t.read_mmd\t= rtl822xb_read_mmd,\ndrivers/net/phy/realtek/realtek_main.c:3216:\t\t.write_mmd\t= rtl822xb_write_mmd,\ndrivers/net/phy/realtek/realtek_main.c-3217-\t}, {\n--\ndrivers/net/phy/realtek/realtek_main.c-3231-\t\t.read_mmd\t= rtl822xb_read_mmd,\ndrivers/net/phy/realtek/realtek_main.c:3232:\t\t.write_mmd\t= rtl822xb_write_mmd,\ndrivers/net/phy/realtek/realtek_main.c-3233-\t}, {\n--\ndrivers/net/phy/realtek/realtek_main.c-3246-\t\t.read_mmd\t= rtl822xb_read_mmd,\ndrivers/net/phy/realtek/realtek_main.c:3247:\t\t.write_mmd\t= rtl822xb_write_mmd,\ndrivers/net/phy/realtek/realtek_main.c-3248-\t}, {\n--\ndrivers/net/phy/realtek/realtek_main.c-3262-\t\t.read_mmd\t= rtl822xb_read_mmd,\ndrivers/net/phy/realtek/realtek_main.c:3263:\t\t.write_mmd\t= rtl822xb_write_mmd,\ndrivers/net/phy/realtek/realtek_main.c-3264-\t}, {\n--\ndrivers/net/phy/realtek/realtek_main.c-3281-\t\t.read_mmd\t= rtl822xb_read_mmd,\ndrivers/net/phy/realtek/realtek_main.c:3282:\t\t.write_mmd\t= rtl822xb_write_mmd,\ndrivers/net/phy/realtek/realtek_main.c-3283-\t\t.led_brightness_set = rtl822xb_led_brightness_set,\n--\ndrivers/net/phy/realtek/realtek_main.c-3304-\t\t.read_mmd\t= rtl822xb_read_mmd,\ndrivers/net/phy/realtek/realtek_main.c:3305:\t\t.write_mmd\t= rtl822xb_write_mmd,\ndrivers/net/phy/realtek/realtek_main.c-3306-\t\t.led_brightness_set = rtl822xb_led_brightness_set,\n--\ndrivers/net/phy/realtek/realtek_main.c-3333-\t\t.read_mmd\t= rtl822x_read_mmd,\ndrivers/net/phy/realtek/realtek_main.c:3334:\t\t.write_mmd\t= rtl822x_write_mmd,\ndrivers/net/phy/realtek/realtek_main.c-3335-\t}, {\n--\ndrivers/net/phy/realtek/realtek_main.c-3347-\t\t.read_mmd\t= rtl822x_read_mmd,\ndrivers/net/phy/realtek/realtek_main.c:3348:\t\t.write_mmd\t= rtl822x_write_mmd,\ndrivers/net/phy/realtek/realtek_main.c-3349-\t}, {\n--\ndrivers/net/phy/realtek/realtek_main.c-3401-\t\t.read_mmd\t= genphy_read_mmd_unsupported,\ndrivers/net/phy/realtek/realtek_main.c:3402:\t\t.write_mmd\t= genphy_write_mmd_unsupported,\ndrivers/net/phy/realtek/realtek_main.c-3403-\t}, {\n"
} |
| 69/2 | 2026/08/06 16:28 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 60918 output: 44 thoughts: 89 Thoughts: Okay, let's break this down. **Investigating `.write_mmd` Implementations** Right, so I'm looking at these `.write_mmd` functions: `rtlgen_write_mmd`, `rtl822x_write_mmd`, and `rtl822xb_write_mmd`. It's pretty clear they all perform a similar, if not identical, function. Standard naming conventions, nothing unusual so far. But wait a minute... I seem to recall something about `rtl822xb_write_mmd`. Wasn't there a call to `rtlgen_write_mmd` within it? That's definitely worth confirming. It's a key bit of information. Let's dig into `rtl822xb_write_mmd` and clarify that dependency. |
| 70/2 | 2026/08/06 16:29 | tool | read-file |
0mArgs:{
"File": "drivers/net/phy/realtek/realtek_main.c",
"FirstLine": 1861,
"LineCount": 20
}Results: {
"Contents": "1861:\tstatic int rtl822xb_write_mmd(struct phy_device *phydev, int devnum, u16 reg,\n1862:\t\t\t\t u16 val)\n1863:\t{\n1864:\t\tint oldpage, ret, write_ret;\n1865:\t\tu16 page;\n1866:\t\n1867:\t\t/* Use default method for all MMDs except MDIO_MMD_VEND2 or in case\n1868:\t\t * Clause-45 access is available\n1869:\t\t */\n1870:\t\tif (devnum != MDIO_MMD_VEND2 || phydev-\u003eis_c45)\n1871:\t\t\treturn mmd_phy_write(phydev-\u003emdio.bus, phydev-\u003emdio.addr,\n1872:\t\t\t\t\t phydev-\u003eis_c45, devnum, reg, val);\n1873:\t\n1874:\t\t/* Simplify access to C22-registers addressed inside MDIO_MMD_VEND2 */\n1875:\t\tif (reg \u003e= RTL822X_VND2_C22_REG(0) \u0026\u0026\n1876:\t\t reg \u003c= RTL822X_VND2_C22_REG(30))\n1877:\t\t\treturn __phy_write(phydev, RTL822X_VND2_TO_C22_REG(reg), val);\n1878:\t\n1879:\t\t/* Use paged access for MDIO_MMD_VEND2 over Clause-22 */\n1880:\t\tpage = RTL822X_VND2_TO_PAGE(reg);\n"
} |
| 71/2 | 2026/08/06 16:29 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 61669 output: 133 thoughts: 566 Thoughts: **My Analysis of the Realtek PHY Driver Patch**
Okay, so the initial assumption about the relationship between `rtl822xb_write_mmd` and `rtlgen_write_mmd` was incorrect. We've established that `rtlgen_write_mmd` and `rtl822x_write_mmd` are the primary functions that utilize `rtlgen_write_vend2` for interacting with the `MDIO_AN_EEE_ADV` register.
Let's zoom in on `rtlgen_write_mmd`. We know this is the function that was patched. Looking at the code:
```c
static int rtlgen_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,
u16 val)
{
int ret;
if (devnum == MDIO_MMD_VEND2)
ret = rtlgen_write_vend2(phydev, regnum, val);
else if (devnum == MDIO_MMD_AN && regnum == MDIO_AN_EEE_ADV)
ret = rtlgen_write_vend2(phydev, RTL_MDIO_AN_EEE_ADV, val);
else
ret = -EOPNOTSUPP;
return ret;
}
```
My reasoning is: The crux of the patch revolves around correcting a potential swap of `regnum` and `val` when calling `rtlgen_write_vend2` within `rtlgen_write_mmd`. The vulnerability could be triggered from userspace via the `SIOCSMIIREG` ioctl or, potentially, through `ETHTOOL_SEEE`, which, in turn, interacts with `rtlgen_write_mmd` and its related functions. This is specifically relevant when a Realtek PHY is connected.
Therefore, the key elements to highlight are:
* **WorthFuzzing: True** (due to the bug and accessibility)
* **FocusSymbols:** `rtlgen_write_mmd`, and `rtl822x_write_mmd` (because they are the ones using the patched function)
* **EnableConfigs:** `REALTEK_PHY` (because it's the specific config required)
Now, a brief check on the static nature of `rtlgen_write_mmd`. Yes, it's declared `static`. However, since it's used with a function pointer (i.e., through ioctl or ethtool), it won't be inlined. This means syzkaller *can* target it, making it a viable focus symbol.
Finally, confirming that `REALTEK_PHY` is a tristate config is crucial. That settles it. Mentioning `PHYLIB` isn't a problem, but `REALTEK_PHY` is the target config.
I'm ready to move on.
|
| 72/2 | 2026/08/06 16:29 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"REALTEK_PHY"
],
"FocusSymbols": [
"rtlgen_write_mmd",
"rtl822x_write_mmd"
],
"Reasoning": "The patch fixes a bug where arguments were swapped in a call to rtlgen_write_vend2 inside rtlgen_write_mmd. This function is a .write_mmd callback for Realtek PHY drivers and is reachable from userspace via SIOCSMIIREG ioctl or ETHTOOL_SEEE when a Realtek PHY is attached.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"REALTEK_PHY"
],
"FocusSymbols": [
"rtlgen_write_mmd",
"rtl822x_write_mmd"
],
"Reasoning": "The patch fixes a bug where arguments were swapped in a call to rtlgen_write_vend2 inside rtlgen_write_mmd. This function is a .write_mmd callback for Realtek PHY drivers and is reachable from userspace via SIOCSMIIREG ioctl or ETHTOOL_SEEE when a Realtek PHY is attached.",
"WorthFuzzing": true
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|