AI Trajectory

Trajectory: (Expand/Collapse All)
Seq	Timestamp	Type	Name	Duration
0/0	2026/08/03 11:33	flow	patch-triage	1m Args: null Results: { "EnableConfigs": null, "FocusSymbols": [], "Reasoning": "This patch introduces a new vendor-specific Ethernet PHY driver for the DAPU Telecom DAP8211R(I). PHY drivers require specific physical hardware to be present on an MDIO bus (or specific device tree configurations and hardware emulation not present in standard QEMU) to be probed and executed. Furthermore, the driver only contains trivial hardware initialization sequences (register reads/writes) and does not expose any complex software interfaces, making it unsuitable and unreachable for fuzzing in a virtualized environment.", "WorthFuzzing": false }
1/1	2026/08/03 11:33	action	read-patch-diff	0m Args: null Results: { "PatchDiff": "commit fa4c54b98e86f9aaf9549db80412556f5faf1653\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Mon Aug 3 11:33:20 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml b/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml\nnew file mode 100644\nindex 0000000000000..fb78fa4f58ca3\n--- /dev/null\n+++ b/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml\n@@ -0,0 +1,62 @@\n+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)\n+%YAML 1.2\n+---\n+$id: http://devicetree.org/schemas/net/dapu,dap8211r.yaml#\n+$schema: http://devicetree.org/meta-schemas/core.yaml#\n+\n+title: DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY\n+\n+maintainers:\n+ - Artem Shimko \u003ca.shimko.dev@gmail.com\u003e\n+\n+description: \|\n+ The DAP8211R(I) is a Gigabit Ethernet PHY with RGMII interface,\n+ supporting IEEE 802.3az Energy Efficient Ethernet, IEEE 1588 SyncE,\n+ and an internal packet generator for diagnostics.\n+\n+ Specifications:\n+ - 10BASE-Te, 100BASE-TX, 1000BASE-T\n+ - RGMII with configurable TX/RX clock delays (150 ps steps, 0-2250 ps)\n+ - IEEE 802.3az-2010 Energy Efficient Ethernet\n+ - IEEE 1588 SyncE support\n+ - Internal packet generator and checker for link diagnostics\n+\n+allOf:\n+ - $ref: ethernet-phy.yaml#\n+\n+properties:\n+ compatible:\n+ const: ethernet-phy-id0008.011b\n+\n+ reg:\n+ maxItems: 1\n+\n+ rx-internal-delay-ps:\n+ description:\n+ RGMII RX clock delay in picoseconds (0 to maximum).\n+ multipleOf: 150\n+ maximum: 2250\n+ default: 1950\n+\n+ tx-internal-delay-ps:\n+ description:\n+ RGMII TX clock delay in picoseconds (0 to maximum).\n+ multipleOf: 150\n+ maximum: 2250\n+ default: 1950\n+\n+unevaluatedProperties: false\n+\n+examples:\n+ - \|\n+ mdio {\n+ #address-cells = \u003c1\u003e;\n+ #size-cells = \u003c0\u003e;\n+\n+ ethernet-phy@1 {\n+ compatible = \"ethernet-phy-id0008.011b\";\n+ reg = \u003c1\u003e;\n+ rx-internal-delay-ps = \u003c2100\u003e;\n+ tx-internal-delay-ps = \u003c2100\u003e;\n+ };\n+ };\ndiff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml\nindex 396044f368e7c..c3db857b98372 100644\n--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml\n+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml\n@@ -403,6 +403,8 @@ patternProperties:\n description: CZ.NIC, z.s.p.o.\n \"^dallas,.\":\n description: Maxim Integrated Products (formerly Dallas Semiconductor)\n+ \"^dapu,.\":\n+ description: Guangdong Dapu Telecom Co., Ltd.\n \"^dataimage,.\":\n description: DataImage, Inc.\n \"^davicom,.\":\ndiff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig\nindex 099f25dceabbc..395bcd35bffa8 100644\n--- a/drivers/net/phy/Kconfig\n+++ b/drivers/net/phy/Kconfig\n@@ -232,6 +232,15 @@ config CORTINA_PHY\n \thelp\n \t Currently supports the CS4340 phy.\n \n+config DAP8211R_PHY\n+\ttristate \"DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY\"\n+\tdepends on OF\n+\thelp\n+\t Support for the DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY.\n+\t This PHY is designed for enterprise and industrial networking\n+\t applications, supporting 10/100/1000 Mbps operation. Supports\n+\t RGMII interface with configurable TX/RX clock delays.\n+\n config DAVICOM_PHY\n \ttristate \"Davicom PHYs\"\n \thelp\ndiff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile\nindex de660ae949453..c72f7730e25da 100644\n--- a/drivers/net/phy/Makefile\n+++ b/drivers/net/phy/Makefile\n@@ -52,6 +52,7 @@ obj-$(CONFIG_BCM_NET_PHYPTP)\t+= bcm-phy-ptp.o\n obj-$(CONFIG_BROADCOM_PHY)\t+= broadcom.o\n obj-$(CONFIG_CICADA_PHY)\t+= cicada.o\n obj-$(CONFIG_CORTINA_PHY)\t+= cortina.o\n+obj-$(CONFIG_DAP8211R_PHY)\t+= dap8211r.o\n obj-$(CONFIG_DAVICOM_PHY)\t+= davicom.o\n obj-$(CONFIG_DP83640_PHY)\t+= dp83640.o\n obj-$(CONFIG_DP83822_PHY)\t+= dp83822.o\ndiff --git a/drivers/net/phy/dap8211r.c b/drivers/net/phy/dap8211r.c\nnew file mode 100644\nindex 0000000000000..f010ce0c3bd13\n--- /dev/null\n+++ b/drivers/net/phy/dap8211r.c\n@@ -0,0 +1,206 @@\n+// SPDX-License-Identifier: GPL-2.0\n+/\n+ Driver for the DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY.\n+ \n+ Specifications:\n+ * - IEEE 802.3 10BASE-Te, 100BASE-TX, 1000BASE-T\n+ * - IEEE 802.3az-2010 Energy Efficient Ethernet\n+ * - IEEE 1588 SyncE support\n+ * - RGMII\n+ \n+ Author: Artem Shimko \u003ca.shimko.dev@gmail.com\u003e\n+ /\n+\n+#include \u003clinux/bitfield.h\u003e\n+#include \u003clinux/errno.h\u003e\n+#include \u003clinux/ethtool.h\u003e\n+#include \u003clinux/kernel.h\u003e\n+#include \u003clinux/iopoll.h\u003e\n+#include \u003clinux/mii.h\u003e\n+#include \u003clinux/module.h\u003e\n+#include \u003clinux/netdevice.h\u003e\n+#include \u003clinux/phy.h\u003e\n+\n+#define DAP8211R_PHY_ID\t\t\t0x0008011B\n+#define DAP8211R_PHY_ID_MASK\t\t0xFFFFFFFF\n+\n+#define DAP8211R_EXT_ADD\t\t0x1E\n+#define DAP8211R_EXT_DATA\t\t0x1F\n+\n+#define DAP8211R_PHY_CON\t\t0xA001\n+#define DAP8211R_PHY_SW_RST\t\tBIT(15)\n+\n+#define DAP8211R_RGMII_CON\t\t0xA003\n+#define DAP8211R_RGMII_TX_DEL_MASK\tGENMASK(3, 0)\n+#define DAP8211R_RGMII_RX_DEL_MASK\tGENMASK(13, 10)\n+\n+#define DAP8211R_RGMII_CONFIG_MASK\t(DAP8211R_RGMII_RX_DEL_MASK \| DAP8211R_RGMII_TX_DEL_MASK)\n+\n+/ Initial RGMII RX delay per hardware specification: 0 * 150ps == 0.00ns /\n+#define DAP8211R_INITIAL_RX_DEL_VAL\t0\n+/ Initial RGMII TX delay per hardware specification: 1 * 150ps == 0.15ns/\n+#define DAP8211R_INITIAL_TX_DEL_VAL\t1\n+/ Default RGMII delay: 13 * 150 == 1.95ns /\n+#define DAP8211R_DEFAULT_DEL_SEL\t0xD\n+\n+static const int dap8211r_internal_delay[] = {0, 150, 300, 450, 600, 750, 900,\n+\t\t\t\t\t 1050, 1200, 1350, 1500, 1650, 1800,\n+\t\t\t\t\t 1950, 2100, 2250};\n+\n+#define DAP8211R_DELAY_SIZE\tARRAY_SIZE(dap8211r_internal_delay)\n+\n+/\n+ dap8211r_read_ext() - Read extended register\n+ * @phydev: PHY device structure\n+ * @reg: Extended register address\n+ \n+ Reads a PHY extended register using the indirect access method.\n+ * The caller must hold the MDIO bus lock.\n+ \n+ Return: Register value on success, or negative error code\n+ /\n+static int dap8211r_read_ext(struct phy_device phydev, u16 reg)\n+{\n+\tint ret;\n+\n+\tphy_lock_mdio_bus(phydev);\n+\tret = __phy_write(phydev, DAP8211R_EXT_ADD, reg);\n+\tif (ret \u003c 0)\n+\t\tgoto out;\n+\n+\tret = __phy_read(phydev, DAP8211R_EXT_DATA);\n+out:\n+\tphy_unlock_mdio_bus(phydev);\n+\treturn ret;\n+}\n+\n+/*\n+ dap8211r_modify_ext() - Modify extended register bits\n+ * @phydev: PHY device structure\n+ * @reg: Extended register address\n+ * @mask: Bit mask of bits to clear\n+ * @set: Bit mask of bits to set\n+ \n+ Modifies a PHY extended register using the indirect access method.\n+ * New value = (old value \u0026 ~mask) \| set.\n+ * The caller must hold the MDIO bus lock.\n+ \n+ Return: 0 on success, or negative error code\n+ /\n+static int dap8211r_modify_ext(struct phy_device phydev, u16 reg, u16 mask, u16 set)\n+{\n+\tint ret;\n+\n+\tphy_lock_mdio_bus(phydev);\n+\tret = __phy_write(phydev, DAP8211R_EXT_ADD, reg);\n+\tif (ret \u003c 0)\n+\t\tgoto out;\n+\n+\tret = __phy_modify(phydev, DAP8211R_EXT_DATA, mask, set);\n+out:\n+\tphy_unlock_mdio_bus(phydev);\n+\treturn ret;\n+}\n+\n+/*\n+ dap8211r_config_init() - Initialize PHY\n+ * @phydev: PHY device structure\n+ \n+ Configures the PHY during initialization:\n+ * - RGMII delays based on interface mode\n+ * - Software reset to apply settings (low active, self clear)\n+ \n+ Return: 0 on success, or negative error code\n+ /\n+static int dap8211r_config_init(struct phy_device phydev)\n+{\n+\tu16 set = 0;\n+\tint ret, val;\n+\ts32 rx_internal_delay = DAP8211R_INITIAL_RX_DEL_VAL;\n+\ts32 tx_internal_delay = DAP8211R_INITIAL_TX_DEL_VAL;\n+\n+\tif (!phy_interface_is_rgmii(phydev))\n+\t\treturn 0;\n+\n+\tif (phydev-\u003einterface != PHY_INTERFACE_MODE_RGMII_TXID)\n+\t\trx_internal_delay = phy_get_internal_delay(phydev, dap8211r_internal_delay,\n+\t\t\t\t\t\t\t DAP8211R_DELAY_SIZE, true);\n+\n+\tif (phydev-\u003einterface != PHY_INTERFACE_MODE_RGMII_RXID)\n+\t\ttx_internal_delay = phy_get_internal_delay(phydev, dap8211r_internal_delay,\n+\t\t\t\t\t\t\t DAP8211R_DELAY_SIZE, false);\n+\n+\tswitch (phydev-\u003einterface) {\n+\tcase PHY_INTERFACE_MODE_RGMII:\n+\t\tif (rx_internal_delay \u003c 0)\n+\t\t\trx_internal_delay = DAP8211R_INITIAL_RX_DEL_VAL;\n+\n+\t\tif (tx_internal_delay \u003c 0)\n+\t\t\ttx_internal_delay = DAP8211R_INITIAL_TX_DEL_VAL;\n+\t\tbreak;\n+\tcase PHY_INTERFACE_MODE_RGMII_RXID:\n+\t\tif (rx_internal_delay \u003c 0)\n+\t\t\trx_internal_delay = DAP8211R_DEFAULT_DEL_SEL;\n+\t\tbreak;\n+\tcase PHY_INTERFACE_MODE_RGMII_ID:\n+\t\tif (rx_internal_delay \u003c 0)\n+\t\t\trx_internal_delay = DAP8211R_DEFAULT_DEL_SEL;\n+\t\tfallthrough;\n+\tcase PHY_INTERFACE_MODE_RGMII_TXID:\n+\t\tif (tx_internal_delay \u003c 0)\n+\t\t\ttx_internal_delay = DAP8211R_DEFAULT_DEL_SEL;\n+\t\tbreak;\n+\tdefault:\n+\t\tphydev_err(phydev, \"Unsupported interface: %d\\n\",\n+\t\t\t phydev-\u003einterface);\n+\t\treturn -EINVAL;\n+\t}\n+\n+\tset \|= FIELD_PREP(DAP8211R_RGMII_RX_DEL_MASK, rx_internal_delay);\n+\tset \|= FIELD_PREP(DAP8211R_RGMII_TX_DEL_MASK, tx_internal_delay);\n+\n+\tret = dap8211r_modify_ext(phydev, DAP8211R_PHY_CON, DAP8211R_PHY_SW_RST, 0);\n+\tif (ret)\n+\t\treturn ret;\n+\n+\t/* Wait for reset self-clear (from low active to high) /\n+\tret = read_poll_timeout(dap8211r_read_ext, val,\n+\t\t\t\t(val \u0026 DAP8211R_PHY_SW_RST),\n+\t\t\t\t20, 200, false, phydev, DAP8211R_PHY_CON);\n+\tif (ret)\n+\t\treturn ret;\n+\tif (val \u003c 0)\n+\t\treturn val;\n+\n+\tret = dap8211r_modify_ext(phydev, DAP8211R_RGMII_CON, DAP8211R_RGMII_CONFIG_MASK, set);\n+\tif (ret)\n+\t\treturn ret;\n+\n+\treturn 0;\n+}\n+\n+static struct phy_driver dap8211r_driver[] = {\n+\t{\n+\t\tPHY_ID_MATCH_EXACT(DAP8211R_PHY_ID),\n+\t\t.name\t\t= \"DAP8211R Gigabit Ethernet\",\n+\t\t.soft_reset\t= genphy_soft_reset,\n+\t\t.config_init\t= dap8211r_config_init,\n+\t\t.read_status\t= genphy_read_status,\n+\t\t.set_loopback\t= genphy_loopback,\n+\t\t.config_aneg\t= genphy_config_aneg,\n+\t\t.suspend\t= genphy_suspend,\n+\t\t.resume\t\t= genphy_resume,\n+\t},\n+};\n+module_phy_driver(dap8211r_driver);\n+\n+MODULE_DESCRIPTION(\"DAP8211R Gigabit Ethernet PHY driver\");\n+MODULE_AUTHOR(\"Artem Shimko \u003ca.shimko.dev@gmail.com\u003e\");\n+MODULE_LICENSE(\"GPL\");\n+\n+static const struct mdio_device_id __maybe_unused dap8211r_tb[] = {\n+\t{ DAP8211R_PHY_ID, DAP8211R_PHY_ID_MASK },\n+\t{ / sentinel */ }\n+};\n+MODULE_DEVICE_TABLE(mdio, dap8211r_tb);\n+\n" }
2/1	2026/08/03 11:33	agent	patch-evaluator	1m Model: best-expensive Args: null Results: { "EnableConfigs": null, "FocusSymbols": [], "Reasoning": "This patch introduces a new vendor-specific Ethernet PHY driver for the DAPU Telecom DAP8211R(I). PHY drivers require specific physical hardware to be present on an MDIO bus (or specific device tree configurations and hardware emulation not present in standard QEMU) to be probed and executed. Furthermore, the driver only contains trivial hardware initialization sequences (register reads/writes) and does not expose any complex software interfaces, making it unsuitable and unreachable for fuzzing in a virtualized environment.", "WorthFuzzing": false } 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 fa4c54b98e86f9aaf9549db80412556f5faf1653 Author: syz-cluster <triage@syzkaller.com> Date: Mon Aug 3 11:33:20 2026 +0000 syz-cluster: applied patch under review diff --git a/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml b/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml new file mode 100644 index 0000000000000..fb78fa4f58ca3 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dapu,dap8211r.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY + +maintainers: + - Artem Shimko <a.shimko.dev@gmail.com> + +description: \| + The DAP8211R(I) is a Gigabit Ethernet PHY with RGMII interface, + supporting IEEE 802.3az Energy Efficient Ethernet, IEEE 1588 SyncE, + and an internal packet generator for diagnostics. + + Specifications: + - 10BASE-Te, 100BASE-TX, 1000BASE-T + - RGMII with configurable TX/RX clock delays (150 ps steps, 0-2250 ps) + - IEEE 802.3az-2010 Energy Efficient Ethernet + - IEEE 1588 SyncE support + - Internal packet generator and checker for link diagnostics + +allOf: + - $ref: ethernet-phy.yaml# + +properties: + compatible: + const: ethernet-phy-id0008.011b + + reg: + maxItems: 1 + + rx-internal-delay-ps: + description: + RGMII RX clock delay in picoseconds (0 to maximum). + multipleOf: 150 + maximum: 2250 + default: 1950 + + tx-internal-delay-ps: + description: + RGMII TX clock delay in picoseconds (0 to maximum). + multipleOf: 150 + maximum: 2250 + default: 1950 + +unevaluatedProperties: false + +examples: + - \| + mdio { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@1 { + compatible = "ethernet-phy-id0008.011b"; + reg = <1>; + rx-internal-delay-ps = <2100>; + tx-internal-delay-ps = <2100>; + }; + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 396044f368e7c..c3db857b98372 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -403,6 +403,8 @@ patternProperties: description: CZ.NIC, z.s.p.o. "^dallas,.": description: Maxim Integrated Products (formerly Dallas Semiconductor) + "^dapu,.": + description: Guangdong Dapu Telecom Co., Ltd. "^dataimage,.": description: DataImage, Inc. "^davicom,.": diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 099f25dceabbc..395bcd35bffa8 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -232,6 +232,15 @@ config CORTINA_PHY help Currently supports the CS4340 phy. +config DAP8211R_PHY + tristate "DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY" + depends on OF + help + Support for the DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY. + This PHY is designed for enterprise and industrial networking + applications, supporting 10/100/1000 Mbps operation. Supports + RGMII interface with configurable TX/RX clock delays. + config DAVICOM_PHY tristate "Davicom PHYs" help diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile index de660ae949453..c72f7730e25da 100644 --- a/drivers/net/phy/Makefile +++ b/drivers/net/phy/Makefile @@ -52,6 +52,7 @@ obj-$(CONFIG_BCM_NET_PHYPTP) += bcm-phy-ptp.o obj-$(CONFIG_BROADCOM_PHY) += broadcom.o obj-$(CONFIG_CICADA_PHY) += cicada.o obj-$(CONFIG_CORTINA_PHY) += cortina.o +obj-$(CONFIG_DAP8211R_PHY) += dap8211r.o obj-$(CONFIG_DAVICOM_PHY) += davicom.o obj-$(CONFIG_DP83640_PHY) += dp83640.o obj-$(CONFIG_DP83822_PHY) += dp83822.o diff --git a/drivers/net/phy/dap8211r.c b/drivers/net/phy/dap8211r.c new file mode 100644 index 0000000000000..f010ce0c3bd13 --- /dev/null +++ b/drivers/net/phy/dap8211r.c @@ -0,0 +1,206 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Driver for the DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY. + * + * Specifications: + * - IEEE 802.3 10BASE-Te, 100BASE-TX, 1000BASE-T + * - IEEE 802.3az-2010 Energy Efficient Ethernet + * - IEEE 1588 SyncE support + * - RGMII + * + * Author: Artem Shimko <a.shimko.dev@gmail.com> + / + +#include <linux/bitfield.h> +#include <linux/errno.h> +#include <linux/ethtool.h> +#include <linux/kernel.h> +#include <linux/iopoll.h> +#include <linux/mii.h> +#include <linux/module.h> +#include <linux/netdevice.h> +#include <linux/phy.h> + +#define DAP8211R_PHY_ID 0x0008011B +#define DAP8211R_PHY_ID_MASK 0xFFFFFFFF + +#define DAP8211R_EXT_ADD 0x1E +#define DAP8211R_EXT_DATA 0x1F + +#define DAP8211R_PHY_CON 0xA001 +#define DAP8211R_PHY_SW_RST BIT(15) + +#define DAP8211R_RGMII_CON 0xA003 +#define DAP8211R_RGMII_TX_DEL_MASK GENMASK(3, 0) +#define DAP8211R_RGMII_RX_DEL_MASK GENMASK(13, 10) + +#define DAP8211R_RGMII_CONFIG_MASK (DAP8211R_RGMII_RX_DEL_MASK \| DAP8211R_RGMII_TX_DEL_MASK) + +/ Initial RGMII RX delay per hardware specification: 0 * 150ps == 0.00ns / +#define DAP8211R_INITIAL_RX_DEL_VAL 0 +/ Initial RGMII TX delay per hardware specification: 1 * 150ps == 0.15ns/ +#define DAP8211R_INITIAL_TX_DEL_VAL 1 +/ Default RGMII delay: 13 * 150 == 1.95ns / +#define DAP8211R_DEFAULT_DEL_SEL 0xD + +static const int dap8211r_internal_delay[] = {0, 150, 300, 450, 600, 750, 900, + 1050, 1200, 1350, 1500, 1650, 1800, + 1950, 2100, 2250}; + +#define DAP8211R_DELAY_SIZE ARRAY_SIZE(dap8211r_internal_delay) + +/* + * dap8211r_read_ext() - Read extended register + * @phydev: PHY device structure + * @reg: Extended register address + * + * Reads a PHY extended register using the indirect access method. + * The caller must hold the MDIO bus lock. + * + * Return: Register value on success, or negative error code + / +static int dap8211r_read_ext(struct phy_device phydev, u16 reg) +{ + int ret; + + phy_lock_mdio_bus(phydev); + ret = __phy_write(phydev, DAP8211R_EXT_ADD, reg); + if (ret < 0) + goto out; + + ret = __phy_read(phydev, DAP8211R_EXT_DATA); +out: + phy_unlock_mdio_bus(phydev); + return ret; +} + +/** + * dap8211r_modify_ext() - Modify extended register bits + * @phydev: PHY device structure + * @reg: Extended register address + * @mask: Bit mask of bits to clear + * @set: Bit mask of bits to set + * + * Modifies a PHY extended register using the indirect access method. + * New value = (old value & ~mask) \| set. + * The caller must hold the MDIO bus lock. + * + * Return: 0 on success, or negative error code + / +static int dap8211r_modify_ext(struct phy_device phydev, u16 reg, u16 mask, u16 set) +{ + int ret; + + phy_lock_mdio_bus(phydev); + ret = __phy_write(phydev, DAP8211R_EXT_ADD, reg); + if (ret < 0) + goto out; + + ret = __phy_modify(phydev, DAP8211R_EXT_DATA, mask, set); +out: + phy_unlock_mdio_bus(phydev); + return ret; +} + +/** + * dap8211r_config_init() - Initialize PHY + * @phydev: PHY device structure + * + * Configures the PHY during initialization: + * - RGMII delays based on interface mode + * - Software reset to apply settings (low active, self clear) + * + * Return: 0 on success, or negative error code + / +static int dap8211r_config_init(struct phy_device phydev) +{ + u16 set = 0; + int ret, val; + s32 rx_internal_delay = DAP8211R_INITIAL_RX_DEL_VAL; + s32 tx_internal_delay = DAP8211R_INITIAL_TX_DEL_VAL; + + if (!phy_interface_is_rgmii(phydev)) + return 0; + + if (phydev->interface != PHY_INTERFACE_MODE_RGMII_TXID) + rx_internal_delay = phy_get_internal_delay(phydev, dap8211r_internal_delay, + DAP8211R_DELAY_SIZE, true); + + if (phydev->interface != PHY_INTERFACE_MODE_RGMII_RXID) + tx_internal_delay = phy_get_internal_delay(phydev, dap8211r_internal_delay, + DAP8211R_DELAY_SIZE, false); + + switch (phydev->interface) { + case PHY_INTERFACE_MODE_RGMII: + if (rx_internal_delay < 0) + rx_internal_delay = DAP8211R_INITIAL_RX_DEL_VAL; + + if (tx_internal_delay < 0) + tx_internal_delay = DAP8211R_INITIAL_TX_DEL_VAL; + break; + case PHY_INTERFACE_MODE_RGMII_RXID: + if (rx_internal_delay < 0) + rx_internal_delay = DAP8211R_DEFAULT_DEL_SEL; + break; + case PHY_INTERFACE_MODE_RGMII_ID: + if (rx_internal_delay < 0) + rx_internal_delay = DAP8211R_DEFAULT_DEL_SEL; + fallthrough; + case PHY_INTERFACE_MODE_RGMII_TXID: + if (tx_internal_delay < 0) + tx_internal_delay = DAP8211R_DEFAULT_DEL_SEL; + break; + default: + phydev_err(phydev, "Unsupported interface: %d\n", + phydev->interface); + return -EINVAL; + } + + set \|= FIELD_PREP(DAP8211R_RGMII_RX_DEL_MASK, rx_internal_delay); + set \|= FIELD_PREP(DAP8211R_RGMII_TX_DEL_MASK, tx_internal_delay); + + ret = dap8211r_modify_ext(phydev, DAP8211R_PHY_CON, DAP8211R_PHY_SW_RST, 0); + if (ret) + return ret; + + /* Wait for reset self-clear (from low active to high) / + ret = read_poll_timeout(dap8211r_read_ext, val, + (val & DAP8211R_PHY_SW_RST), + 20, 200, false, phydev, DAP8211R_PHY_CON); + if (ret) + return ret; + if (val < 0) + return val; + + ret = dap8211r_modify_ext(phydev, DAP8211R_RGMII_CON, DAP8211R_RGMII_CONFIG_MASK, set); + if (ret) + return ret; + + return 0; +} + +static struct phy_driver dap8211r_driver[] = { + { + PHY_ID_MATCH_EXACT(DAP8211R_PHY_ID), + .name = "DAP8211R Gigabit Ethernet", + .soft_reset = genphy_soft_reset, + .config_init = dap8211r_config_init, + .read_status = genphy_read_status, + .set_loopback = genphy_loopback, + .config_aneg = genphy_config_aneg, + .suspend = genphy_suspend, + .resume = genphy_resume, + }, +}; +module_phy_driver(dap8211r_driver); + +MODULE_DESCRIPTION("DAP8211R Gigabit Ethernet PHY driver"); +MODULE_AUTHOR("Artem Shimko <a.shimko.dev@gmail.com>"); +MODULE_LICENSE("GPL"); + +static const struct mdio_device_id __maybe_unused dap8211r_tb[] = { + { DAP8211R_PHY_ID, DAP8211R_PHY_ID_MASK }, + { / sentinel */ } +}; +MODULE_DEVICE_TABLE(mdio, dap8211r_tb); +
3/2	2026/08/03 11:33	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 6163 output: 19 thoughts: 1131 Thoughts: Assessing the Fuzzability of the DAP8211R PHY Driver Okay, so we have a new PHY driver here for the DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY. The patch is pretty straightforward: documentation, Kconfig, Makefile, and the driver itself (`dap8211r.c`). The driver implements the standard PHY initialization, read/modify functions and utilizes some generic PHY functions. My initial thought is, can we actually reach this in a virtualized environment? PHY drivers, as we know, are probed via the MDIO bus. QEMU might have MDIO buses on some network devices, allowing PHY probing based on device tree configurations or driver instantiation. However, specific PHY drivers usually probe only if the hardware reports their specific ID (in this case `0x0008011B`) or if the device tree explicitly lists a compatible string. Can syzkaller fuzz this? That's the key question. Can it instantiate the driver? Syzkaller has some network capabilities with `syz_genetlink_get_family` and such, but for PHYs it hinges on the MDIO bus. Can userspace somehow directly instantiate a PHY driver through sysfs or netlink? No, normally PHYs are probed via MDIO scanning. So, for syzkaller to reach this, we'd need an emulated MDIO bus, or perhaps a virtual driver. Does syzkaller have this? I know it can inject MDIO frames in the right circumstances. It doesn't seem to, but maybe through the right mechanisms. I'm thinking of something like `macsec` or `dummy` but those don't have MDIO. Let's think about the driver itself. `dap8211r_config_init` is called when the PHY is initialized. It's the entry point. Is this worth fuzzing? PHY drivers are often very hardware-specific, which makes reaching them difficult without emulating the exact hardware. Let's think about the instructions for determining if a patch is worth fuzzing. The instructions mention that code in vendor-specific PCIe switch, SmartNIC, or GPU drivers is not worth fuzzing if they require physical PCIe hardware cards not emulated in standard QEMU. This seems similar: it's a vendor-specific Ethernet PHY driver. It requires an MDIO bus and the specific PHY hardware, or at least a matching device tree node. Can we reach it in standard QEMU? Probably not. QEMU emulates generic PHYs, but not this specific one, DAP8211R. Also, the driver is very simple; mostly register reads and writes. I'm thinking, is there any way to trigger this? And, if we can't easily reach it, we should mark it as not worth fuzzing. I need to double-check if syzkaller has some advanced MDIO injection tricks. I'll search syzkaller for `mdio`. The prompt specifically says to avoid code paths that are impossible to reach in virtualized environments. PHY drivers are generally in that category, unless there's a specific emulation or a userspace-controllable software MDIO bus. Is there a software MDIO bus? I'll check the `drivers/net/phy/` directory for something like `mdio-mockup` or `mdio-gpio` that could be instantiated from userspace. Even if one exists, the driver itself is extremely simple. Okay, I'm going to mark this as WorthFuzzing=false. It's a vendor-specific PHY driver that requires either physical hardware (or specific device tree configuration) or a very specific QEMU emulation. Standard QEMU, I'm pretty sure, won't cut it. I need to go over the virtual MDIO drivers.
4/2	2026/08/03 11:33	tool	grepper	0m Error: no matches Args: { "Expression": "mdio.mockup" } Results:* { "error": "no matches" }
5/2	2026/08/03 11:33	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 8151 output: 24 thoughts: 51 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: Investigating Userspace MDIO Driver Interaction Alright, time to dive in. I need to figure out if there's a mechanism in the current kernel that allows for user-space instantiation of an `mdio` driver. My immediate focus will be on the typical driver locations, so I'll be searching through `drivers/net/phy/` and `drivers/net/mdio/`. I'm looking for anything that suggests a means for user-space programs to interface with or even directly manage an MDIO PHY. Essentially, is there a user-space API built on top of the MDIO bus code? I need to understand if the kernel provides a framework for userland to register and control its own MDIO drivers and manage MDIO devices directly, rather than solely through the standard network interface setup.
6/2	2026/08/03 11:33	tool	codesearch-dir-index	0m Args: { "Dir": "drivers/net/mdio" } Results: { "Files": [ "acpi_mdio.c", "fwnode_mdio.c", "mdio-airoha.c", "mdio-aspeed.c", "mdio-bcm-iproc.c", "mdio-bcm-unimac.c", "mdio-bitbang.c", "mdio-cavium.c", "mdio-cavium.h", "mdio-gpio.c", "mdio-hisi-femac.c", "mdio-i2c.c", "mdio-ipq4019.c", "mdio-ipq8064.c", "mdio-moxart.c", "mdio-mscc-miim.c", "mdio-mux-bcm-iproc.c", "mdio-mux-bcm6368.c", "mdio-mux-gpio.c", "mdio-mux-meson-g12a.c", "mdio-mux-meson-gxl.c", "mdio-mux-mmioreg.c", "mdio-mux-multiplexer.c", "mdio-mux.c", "mdio-mvusb.c", "mdio-octeon.c", "mdio-pic64hpsc.c", "mdio-realtek-rtl9300.c", "mdio-regmap.c", "mdio-sun4i.c", "mdio-thunder.c", "mdio-xgene.c", "of_mdio.c" ], "Subdirs": null }
7/2	2026/08/03 11:33	llm	patch-evaluator	1m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 8815 output: 19 thoughts: 79 Thoughts: Okay, let's break this down. Potential for Syzkaller Integration: USB-based MDIO Adapter Right, so I'm thinking about MDIO drivers here. Specifically, I'm seeing references to `mdio-gpio.c`, `mdio-i2c.c`, and then this interesting one: `mdio-mvusb.c`. A USB to MDIO adapter... that's the Marvell USB MDIO Adapter, if I recall correctly. Now my mind immediately jumps to Syzkaller. If we could emulate this USB gadget, that opens up a whole new attack surface for fuzzing. This could be a significant discovery. The implications are potentially huge for testing this kind of hardware. So, where to start? Let's dive into `mdio-mvusb.c` and see what makes it tick.
8/2	2026/08/03 11:34	tool	grepper	0m Args: { "Expression": "Marvell USB MDIO" } Results: { "Output": "drivers/net/mdio/mdio-mvusb.c=111=MODULE_AUTHOR(\"Tobias Waldekranz \u003ctobias@waldekranz.com\u003e\");\ndrivers/net/mdio/mdio-mvusb.c:112:MODULE_DESCRIPTION(\"Marvell USB MDIO Adapter\");\ndrivers/net/mdio/mdio-mvusb.c-113-MODULE_LICENSE(\"GPL\");\n" }
9/2	2026/08/03 11:34	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 9205 output: 24 thoughts: 222 Thoughts: Emulating the Marvell USB MDIO Adapter in Syzkaller: A Feasibility Analysis Okay, so I'm thinking about how syzkaller could possibly emulate this Marvell USB MDIO adapter. If we could get it to register an MDIO bus, that would be a huge step. But then the question becomes, how does it instantiate the specific PHY? My understanding is that the PHY is typically discovered through probing the MDIO bus. If the emulated USB device could somehow respond to MDIO reads on those crucial PHY ID registers (registers 2 and 3, to be precise), and returned `0x0008011B`, the kernel would happily load and bind the `dap8211r` driver. Bingo! But that brings up the big question: does syzkaller's USB fuzzer even know how to respond to MDIO read requests when dealing with the Marvell USB protocol? That's the crux of it, right? I'm assuming the Marvell USB MDIO adapter protocol is relatively straightforward. Syzkaller's USB fuzzer generates responses randomly, in general. So there's always a theoretical possibility of it accidentally returning the correct PHY ID, but the probability of it randomly hitting exactly `0x0008011B` in the right registers is vanishingly small. We'd essentially be talking about winning the lottery. Unless, of course, there are existing syzlang descriptions specifically for this protocol, which would make the chance of generating that magic number much higher. Right, so I need to check if there are any syzkaller descriptions, or any information at all, that deal with `mdio` or `mvusb`. That's the next step in my investigation.
10/2	2026/08/03 11:34	tool	grepper	0m Error: no matches Args: { "Expression": "mdio", "PathPrefix": "sys/" } Results: { "error": "no matches" }
11/2	2026/08/03 11:34	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 9845 output: 132 thoughts: 887 Thoughts: Fuzzing Decision for the DAP8211R PHY Driver Okay, first things first, I need to remember that `grepper` is off-limits for `sys/` files, specifically the syzkaller language descriptions. I need to use `read-syz-spec` or `syz-grepper` for those, but neither of those tools is in my current arsenal. So, checking syzlang descriptions is out. Even if I could get at the syzlang, this driver itself looks incredibly simple. I see the code, and it's just a sequence of MDIO reads and writes. It's essentially initializing a piece of hardware. No complex logic, no Netlink interfaces, no sysfs attributes, nothing that would be interesting from a fuzzing perspective. Fuzzing this thing would basically boil down to randomly returning values from the `dap8211r_read_ext` function. Is that really worth the effort? Now, let's think about the "WorthFuzzing" criteria. My internal rule says, "Return WorthFuzzing=false if the patch only contains...Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers...that require physical PCIe hardware cards not emulated in standard QEMU". This DAP8211R driver is a vendor-specific Ethernet PHY. It requires the physical DAP8211R hardware. Theoretically, I could maybe reach it with a USB-MDIO adapter and random USB responses, but that's a long shot and not the intended setup. It's impractical and not what this fuzzer is designed for. Plus, it's a vendor-specific hardware driver, which is another mark against it. Okay, let's consider other avenues to reach it. Device tree? Syzkaller doesn't typically inject arbitrary device trees at runtime (barring overlays, but that's restricted). Nope. That's not a path. So, here's my conclusion: This is a vendor-specific Ethernet PHY driver that requires physical hardware not emulated in standard QEMU. Its logic is extremely trivial—just a register initialization sequence. Therefore, it's not worth fuzzing. I'm going to document the reasoning concisely as follows: "This patch introduces a new vendor-specific Ethernet PHY driver for the DAPU Telecom DAP8211R(I). PHY drivers require specific physical hardware to be present on an MDIO bus (or specific device tree configurations and hardware emulation not present in standard QEMU) to be probed and executed. Furthermore, the driver only contains trivial hardware initialization sequences (register reads/writes) and does not expose any complex software interfaces, making it unsuitable and unreachable for fuzzing in a virtualized environment." Just to be absolutely certain, I'll quickly check the other modified files to make sure nothing else sneaky is going on. I'll look at `Documentation/devicetree/bindings/net/dapu,dap8211r.yaml`, `Documentation/devicetree/bindings/vendor-prefixes.yaml`, `drivers/net/phy/Kconfig`, `drivers/net/phy/Makefile`, and `drivers/net/phy/dap8211r.c`. Okay, it's all directly related to this one PHY driver. Alright, I'm setting `WorthFuzzing=false`.
12/2	2026/08/03 11:35	tool	set-results	0m Args: { "EnableConfigs": [], "FocusSymbols": [], "Reasoning": "This patch introduces a new vendor-specific Ethernet PHY driver for the DAPU Telecom DAP8211R(I). PHY drivers require specific physical hardware to be present on an MDIO bus (or specific device tree configurations and hardware emulation not present in standard QEMU) to be probed and executed. Furthermore, the driver only contains trivial hardware initialization sequences (register reads/writes) and does not expose any complex software interfaces, making it unsuitable and unreachable for fuzzing in a virtualized environment.", "WorthFuzzing": false } Results: { "EnableConfigs": null, "FocusSymbols": [], "Reasoning": "This patch introduces a new vendor-specific Ethernet PHY driver for the DAPU Telecom DAP8211R(I). PHY drivers require specific physical hardware to be present on an MDIO bus (or specific device tree configurations and hardware emulation not present in standard QEMU) to be probed and executed. Furthermore, the driver only contains trivial hardware initialization sequences (register reads/writes) and does not expose any complex software interfaces, making it unsuitable and unreachable for fuzzing in a virtualized environment.", "WorthFuzzing": false }

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "This patch introduces a new vendor-specific Ethernet PHY driver for the DAPU Telecom DAP8211R(I). PHY drivers require specific physical hardware to be present on an MDIO bus (or specific device tree configurations and hardware emulation not present in standard QEMU) to be probed and executed. Furthermore, the driver only contains trivial hardware initialization sequences (register reads/writes) and does not expose any complex software interfaces, making it unsuitable and unreachable for fuzzing in a virtualized environment.",
  "WorthFuzzing": false
}

{
  "PatchDiff": "commit fa4c54b98e86f9aaf9549db80412556f5faf1653\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Mon Aug 3 11:33:20 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml b/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml\nnew file mode 100644\nindex 0000000000000..fb78fa4f58ca3\n--- /dev/null\n+++ b/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml\n@@ -0,0 +1,62 @@\n+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)\n+%YAML 1.2\n+---\n+$id: http://devicetree.org/schemas/net/dapu,dap8211r.yaml#\n+$schema: http://devicetree.org/meta-schemas/core.yaml#\n+\n+title: DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY\n+\n+maintainers:\n+  - Artem Shimko \u003ca.shimko.dev@gmail.com\u003e\n+\n+description: |\n+  The DAP8211R(I) is a Gigabit Ethernet PHY with RGMII interface,\n+  supporting IEEE 802.3az Energy Efficient Ethernet, IEEE 1588 SyncE,\n+  and an internal packet generator for diagnostics.\n+\n+  Specifications:\n+    - 10BASE-Te, 100BASE-TX, 1000BASE-T\n+    - RGMII with configurable TX/RX clock delays (150 ps steps, 0-2250 ps)\n+    - IEEE 802.3az-2010 Energy Efficient Ethernet\n+    - IEEE 1588 SyncE support\n+    - Internal packet generator and checker for link diagnostics\n+\n+allOf:\n+  - $ref: ethernet-phy.yaml#\n+\n+properties:\n+  compatible:\n+    const: ethernet-phy-id0008.011b\n+\n+  reg:\n+    maxItems: 1\n+\n+  rx-internal-delay-ps:\n+    description:\n+      RGMII RX clock delay in picoseconds (0 to maximum).\n+    multipleOf: 150\n+    maximum: 2250\n+    default: 1950\n+\n+  tx-internal-delay-ps:\n+    description:\n+      RGMII TX clock delay in picoseconds (0 to maximum).\n+    multipleOf: 150\n+    maximum: 2250\n+    default: 1950\n+\n+unevaluatedProperties: false\n+\n+examples:\n+  - |\n+    mdio {\n+        #address-cells = \u003c1\u003e;\n+        #size-cells = \u003c0\u003e;\n+\n+        ethernet-phy@1 {\n+            compatible = \"ethernet-phy-id0008.011b\";\n+            reg = \u003c1\u003e;\n+            rx-internal-delay-ps = \u003c2100\u003e;\n+            tx-internal-delay-ps = \u003c2100\u003e;\n+        };\n+    };\ndiff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml\nindex 396044f368e7c..c3db857b98372 100644\n--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml\n+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml\n@@ -403,6 +403,8 @@ patternProperties:\n     description: CZ.NIC, z.s.p.o.\n   \"^dallas,.*\":\n     description: Maxim Integrated Products (formerly Dallas Semiconductor)\n+  \"^dapu,.*\":\n+    description: Guangdong Dapu Telecom Co., Ltd.\n   \"^dataimage,.*\":\n     description: DataImage, Inc.\n   \"^davicom,.*\":\ndiff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig\nindex 099f25dceabbc..395bcd35bffa8 100644\n--- a/drivers/net/phy/Kconfig\n+++ b/drivers/net/phy/Kconfig\n@@ -232,6 +232,15 @@ config CORTINA_PHY\n \thelp\n \t  Currently supports the CS4340 phy.\n \n+config DAP8211R_PHY\n+\ttristate \"DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY\"\n+\tdepends on OF\n+\thelp\n+\t  Support for the DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY.\n+\t  This PHY is designed for enterprise and industrial networking\n+\t  applications, supporting 10/100/1000 Mbps operation. Supports\n+\t  RGMII interface with configurable TX/RX clock delays.\n+\n config DAVICOM_PHY\n \ttristate \"Davicom PHYs\"\n \thelp\ndiff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile\nindex de660ae949453..c72f7730e25da 100644\n--- a/drivers/net/phy/Makefile\n+++ b/drivers/net/phy/Makefile\n@@ -52,6 +52,7 @@ obj-$(CONFIG_BCM_NET_PHYPTP)\t+= bcm-phy-ptp.o\n obj-$(CONFIG_BROADCOM_PHY)\t+= broadcom.o\n obj-$(CONFIG_CICADA_PHY)\t+= cicada.o\n obj-$(CONFIG_CORTINA_PHY)\t+= cortina.o\n+obj-$(CONFIG_DAP8211R_PHY)\t+= dap8211r.o\n obj-$(CONFIG_DAVICOM_PHY)\t+= davicom.o\n obj-$(CONFIG_DP83640_PHY)\t+= dp83640.o\n obj-$(CONFIG_DP83822_PHY)\t+= dp83822.o\ndiff --git a/drivers/net/phy/dap8211r.c b/drivers/net/phy/dap8211r.c\nnew file mode 100644\nindex 0000000000000..f010ce0c3bd13\n--- /dev/null\n+++ b/drivers/net/phy/dap8211r.c\n@@ -0,0 +1,206 @@\n+// SPDX-License-Identifier: GPL-2.0\n+/*\n+ * Driver for the DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY.\n+ *\n+ * Specifications:\n+ *   - IEEE 802.3 10BASE-Te, 100BASE-TX, 1000BASE-T\n+ *   - IEEE 802.3az-2010 Energy Efficient Ethernet\n+ *   - IEEE 1588 SyncE support\n+ *   - RGMII\n+ *\n+ * Author: Artem Shimko \u003ca.shimko.dev@gmail.com\u003e\n+ */\n+\n+#include \u003clinux/bitfield.h\u003e\n+#include \u003clinux/errno.h\u003e\n+#include \u003clinux/ethtool.h\u003e\n+#include \u003clinux/kernel.h\u003e\n+#include \u003clinux/iopoll.h\u003e\n+#include \u003clinux/mii.h\u003e\n+#include \u003clinux/module.h\u003e\n+#include \u003clinux/netdevice.h\u003e\n+#include \u003clinux/phy.h\u003e\n+\n+#define DAP8211R_PHY_ID\t\t\t0x0008011B\n+#define DAP8211R_PHY_ID_MASK\t\t0xFFFFFFFF\n+\n+#define DAP8211R_EXT_ADD\t\t0x1E\n+#define DAP8211R_EXT_DATA\t\t0x1F\n+\n+#define DAP8211R_PHY_CON\t\t0xA001\n+#define DAP8211R_PHY_SW_RST\t\tBIT(15)\n+\n+#define DAP8211R_RGMII_CON\t\t0xA003\n+#define DAP8211R_RGMII_TX_DEL_MASK\tGENMASK(3, 0)\n+#define DAP8211R_RGMII_RX_DEL_MASK\tGENMASK(13, 10)\n+\n+#define DAP8211R_RGMII_CONFIG_MASK\t(DAP8211R_RGMII_RX_DEL_MASK | DAP8211R_RGMII_TX_DEL_MASK)\n+\n+/* Initial RGMII RX delay per hardware specification: 0 * 150ps == 0.00ns */\n+#define DAP8211R_INITIAL_RX_DEL_VAL\t0\n+/* Initial RGMII TX delay per hardware specification: 1 * 150ps == 0.15ns*/\n+#define DAP8211R_INITIAL_TX_DEL_VAL\t1\n+/* Default RGMII delay: 13 * 150 == 1.95ns */\n+#define DAP8211R_DEFAULT_DEL_SEL\t0xD\n+\n+static const int dap8211r_internal_delay[] = {0, 150, 300, 450, 600, 750, 900,\n+\t\t\t\t\t      1050, 1200, 1350, 1500, 1650, 1800,\n+\t\t\t\t\t      1950, 2100, 2250};\n+\n+#define DAP8211R_DELAY_SIZE\tARRAY_SIZE(dap8211r_internal_delay)\n+\n+/**\n+ * dap8211r_read_ext() - Read extended register\n+ * @phydev: PHY device structure\n+ * @reg: Extended register address\n+ *\n+ * Reads a PHY extended register using the indirect access method.\n+ * The caller must hold the MDIO bus lock.\n+ *\n+ * Return: Register value on success, or negative error code\n+ */\n+static int dap8211r_read_ext(struct phy_device *phydev, u16 reg)\n+{\n+\tint ret;\n+\n+\tphy_lock_mdio_bus(phydev);\n+\tret = __phy_write(phydev, DAP8211R_EXT_ADD, reg);\n+\tif (ret \u003c 0)\n+\t\tgoto out;\n+\n+\tret = __phy_read(phydev, DAP8211R_EXT_DATA);\n+out:\n+\tphy_unlock_mdio_bus(phydev);\n+\treturn ret;\n+}\n+\n+/**\n+ * dap8211r_modify_ext() - Modify extended register bits\n+ * @phydev: PHY device structure\n+ * @reg: Extended register address\n+ * @mask: Bit mask of bits to clear\n+ * @set: Bit mask of bits to set\n+ *\n+ * Modifies a PHY extended register using the indirect access method.\n+ * New value = (old value \u0026 ~mask) | set.\n+ * The caller must hold the MDIO bus lock.\n+ *\n+ * Return: 0 on success, or negative error code\n+ */\n+static int dap8211r_modify_ext(struct phy_device *phydev, u16 reg, u16 mask, u16 set)\n+{\n+\tint ret;\n+\n+\tphy_lock_mdio_bus(phydev);\n+\tret = __phy_write(phydev, DAP8211R_EXT_ADD, reg);\n+\tif (ret \u003c 0)\n+\t\tgoto out;\n+\n+\tret = __phy_modify(phydev, DAP8211R_EXT_DATA, mask, set);\n+out:\n+\tphy_unlock_mdio_bus(phydev);\n+\treturn ret;\n+}\n+\n+/**\n+ * dap8211r_config_init() - Initialize PHY\n+ * @phydev: PHY device structure\n+ *\n+ * Configures the PHY during initialization:\n+ * - RGMII delays based on interface mode\n+ * - Software reset to apply settings (low active, self clear)\n+ *\n+ * Return: 0 on success, or negative error code\n+ */\n+static int dap8211r_config_init(struct phy_device *phydev)\n+{\n+\tu16 set = 0;\n+\tint ret, val;\n+\ts32 rx_internal_delay = DAP8211R_INITIAL_RX_DEL_VAL;\n+\ts32 tx_internal_delay = DAP8211R_INITIAL_TX_DEL_VAL;\n+\n+\tif (!phy_interface_is_rgmii(phydev))\n+\t\treturn 0;\n+\n+\tif (phydev-\u003einterface != PHY_INTERFACE_MODE_RGMII_TXID)\n+\t\trx_internal_delay = phy_get_internal_delay(phydev, dap8211r_internal_delay,\n+\t\t\t\t\t\t\t   DAP8211R_DELAY_SIZE, true);\n+\n+\tif (phydev-\u003einterface != PHY_INTERFACE_MODE_RGMII_RXID)\n+\t\ttx_internal_delay = phy_get_internal_delay(phydev, dap8211r_internal_delay,\n+\t\t\t\t\t\t\t   DAP8211R_DELAY_SIZE, false);\n+\n+\tswitch (phydev-\u003einterface) {\n+\tcase PHY_INTERFACE_MODE_RGMII:\n+\t\tif (rx_internal_delay \u003c 0)\n+\t\t\trx_internal_delay = DAP8211R_INITIAL_RX_DEL_VAL;\n+\n+\t\tif (tx_internal_delay \u003c 0)\n+\t\t\ttx_internal_delay = DAP8211R_INITIAL_TX_DEL_VAL;\n+\t\tbreak;\n+\tcase PHY_INTERFACE_MODE_RGMII_RXID:\n+\t\tif (rx_internal_delay \u003c 0)\n+\t\t\trx_internal_delay = DAP8211R_DEFAULT_DEL_SEL;\n+\t\tbreak;\n+\tcase PHY_INTERFACE_MODE_RGMII_ID:\n+\t\tif (rx_internal_delay \u003c 0)\n+\t\t\trx_internal_delay = DAP8211R_DEFAULT_DEL_SEL;\n+\t\tfallthrough;\n+\tcase PHY_INTERFACE_MODE_RGMII_TXID:\n+\t\tif (tx_internal_delay \u003c 0)\n+\t\t\ttx_internal_delay = DAP8211R_DEFAULT_DEL_SEL;\n+\t\tbreak;\n+\tdefault:\n+\t\tphydev_err(phydev, \"Unsupported interface: %d\\n\",\n+\t\t\t   phydev-\u003einterface);\n+\t\treturn -EINVAL;\n+\t}\n+\n+\tset |= FIELD_PREP(DAP8211R_RGMII_RX_DEL_MASK, rx_internal_delay);\n+\tset |= FIELD_PREP(DAP8211R_RGMII_TX_DEL_MASK, tx_internal_delay);\n+\n+\tret = dap8211r_modify_ext(phydev, DAP8211R_PHY_CON, DAP8211R_PHY_SW_RST, 0);\n+\tif (ret)\n+\t\treturn ret;\n+\n+\t/* Wait for reset self-clear (from low active to high) */\n+\tret = read_poll_timeout(dap8211r_read_ext, val,\n+\t\t\t\t(val \u0026 DAP8211R_PHY_SW_RST),\n+\t\t\t\t20, 200, false, phydev, DAP8211R_PHY_CON);\n+\tif (ret)\n+\t\treturn ret;\n+\tif (val \u003c 0)\n+\t\treturn val;\n+\n+\tret = dap8211r_modify_ext(phydev, DAP8211R_RGMII_CON, DAP8211R_RGMII_CONFIG_MASK, set);\n+\tif (ret)\n+\t\treturn ret;\n+\n+\treturn 0;\n+}\n+\n+static struct phy_driver dap8211r_driver[] = {\n+\t{\n+\t\tPHY_ID_MATCH_EXACT(DAP8211R_PHY_ID),\n+\t\t.name\t\t= \"DAP8211R Gigabit Ethernet\",\n+\t\t.soft_reset\t= genphy_soft_reset,\n+\t\t.config_init\t= dap8211r_config_init,\n+\t\t.read_status\t= genphy_read_status,\n+\t\t.set_loopback\t= genphy_loopback,\n+\t\t.config_aneg\t= genphy_config_aneg,\n+\t\t.suspend\t= genphy_suspend,\n+\t\t.resume\t\t= genphy_resume,\n+\t},\n+};\n+module_phy_driver(dap8211r_driver);\n+\n+MODULE_DESCRIPTION(\"DAP8211R Gigabit Ethernet PHY driver\");\n+MODULE_AUTHOR(\"Artem Shimko \u003ca.shimko.dev@gmail.com\u003e\");\n+MODULE_LICENSE(\"GPL\");\n+\n+static const struct mdio_device_id __maybe_unused dap8211r_tb[] = {\n+\t{ DAP8211R_PHY_ID, DAP8211R_PHY_ID_MASK },\n+\t{ /* sentinel */ }\n+};\n+MODULE_DEVICE_TABLE(mdio, dap8211r_tb);\n+\n"
}

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "This patch introduces a new vendor-specific Ethernet PHY driver for the DAPU Telecom DAP8211R(I). PHY drivers require specific physical hardware to be present on an MDIO bus (or specific device tree configurations and hardware emulation not present in standard QEMU) to be probed and executed. Furthermore, the driver only contains trivial hardware initialization sequences (register reads/writes) and does not expose any complex software interfaces, making it unsuitable and unreachable for fuzzing in a virtualized environment.",
  "WorthFuzzing": false
}

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.

For your convenience, here is the diff of the changes:
commit fa4c54b98e86f9aaf9549db80412556f5faf1653
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Aug 3 11:33:20 2026 +0000

    syz-cluster: applied patch under review

diff --git a/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml b/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml
new file mode 100644
index 0000000000000..fb78fa4f58ca3
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dapu,dap8211r.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY
+
+maintainers:
+  - Artem Shimko <a.shimko.dev@gmail.com>
+
+description: |
+  The DAP8211R(I) is a Gigabit Ethernet PHY with RGMII interface,
+  supporting IEEE 802.3az Energy Efficient Ethernet, IEEE 1588 SyncE,
+  and an internal packet generator for diagnostics.
+
+  Specifications:
+    - 10BASE-Te, 100BASE-TX, 1000BASE-T
+    - RGMII with configurable TX/RX clock delays (150 ps steps, 0-2250 ps)
+    - IEEE 802.3az-2010 Energy Efficient Ethernet
+    - IEEE 1588 SyncE support
+    - Internal packet generator and checker for link diagnostics
+
+allOf:
+  - $ref: ethernet-phy.yaml#
+
+properties:
+  compatible:
+    const: ethernet-phy-id0008.011b
+
+  reg:
+    maxItems: 1
+
+  rx-internal-delay-ps:
+    description:
+      RGMII RX clock delay in picoseconds (0 to maximum).
+    multipleOf: 150
+    maximum: 2250
+    default: 1950
+
+  tx-internal-delay-ps:
+    description:
+      RGMII TX clock delay in picoseconds (0 to maximum).
+    multipleOf: 150
+    maximum: 2250
+    default: 1950
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    mdio {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        ethernet-phy@1 {
+            compatible = "ethernet-phy-id0008.011b";
+            reg = <1>;
+            rx-internal-delay-ps = <2100>;
+            tx-internal-delay-ps = <2100>;
+        };
+    };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 396044f368e7c..c3db857b98372 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -403,6 +403,8 @@ patternProperties:
     description: CZ.NIC, z.s.p.o.
   "^dallas,.*":
     description: Maxim Integrated Products (formerly Dallas Semiconductor)
+  "^dapu,.*":
+    description: Guangdong Dapu Telecom Co., Ltd.
   "^dataimage,.*":
     description: DataImage, Inc.
   "^davicom,.*":
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 099f25dceabbc..395bcd35bffa8 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -232,6 +232,15 @@ config CORTINA_PHY
 	help
 	  Currently supports the CS4340 phy.
 
+config DAP8211R_PHY
+	tristate "DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY"
+	depends on OF
+	help
+	  Support for the DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY.
+	  This PHY is designed for enterprise and industrial networking
+	  applications, supporting 10/100/1000 Mbps operation. Supports
+	  RGMII interface with configurable TX/RX clock delays.
+
 config DAVICOM_PHY
 	tristate "Davicom PHYs"
 	help
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index de660ae949453..c72f7730e25da 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_BCM_NET_PHYPTP)	+= bcm-phy-ptp.o
 obj-$(CONFIG_BROADCOM_PHY)	+= broadcom.o
 obj-$(CONFIG_CICADA_PHY)	+= cicada.o
 obj-$(CONFIG_CORTINA_PHY)	+= cortina.o
+obj-$(CONFIG_DAP8211R_PHY)	+= dap8211r.o
 obj-$(CONFIG_DAVICOM_PHY)	+= davicom.o
 obj-$(CONFIG_DP83640_PHY)	+= dp83640.o
 obj-$(CONFIG_DP83822_PHY)	+= dp83822.o
diff --git a/drivers/net/phy/dap8211r.c b/drivers/net/phy/dap8211r.c
new file mode 100644
index 0000000000000..f010ce0c3bd13
--- /dev/null
+++ b/drivers/net/phy/dap8211r.c
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY.
+ *
+ * Specifications:
+ *   - IEEE 802.3 10BASE-Te, 100BASE-TX, 1000BASE-T
+ *   - IEEE 802.3az-2010 Energy Efficient Ethernet
+ *   - IEEE 1588 SyncE support
+ *   - RGMII
+ *
+ * Author: Artem Shimko <a.shimko.dev@gmail.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/errno.h>
+#include <linux/ethtool.h>
+#include <linux/kernel.h>
+#include <linux/iopoll.h>
+#include <linux/mii.h>
+#include <linux/module.h>
+#include <linux/netdevice.h>
+#include <linux/phy.h>
+
+#define DAP8211R_PHY_ID			0x0008011B
+#define DAP8211R_PHY_ID_MASK		0xFFFFFFFF
+
+#define DAP8211R_EXT_ADD		0x1E
+#define DAP8211R_EXT_DATA		0x1F
+
+#define DAP8211R_PHY_CON		0xA001
+#define DAP8211R_PHY_SW_RST		BIT(15)
+
+#define DAP8211R_RGMII_CON		0xA003
+#define DAP8211R_RGMII_TX_DEL_MASK	GENMASK(3, 0)
+#define DAP8211R_RGMII_RX_DEL_MASK	GENMASK(13, 10)
+
+#define DAP8211R_RGMII_CONFIG_MASK	(DAP8211R_RGMII_RX_DEL_MASK | DAP8211R_RGMII_TX_DEL_MASK)
+
+/* Initial RGMII RX delay per hardware specification: 0 * 150ps == 0.00ns */
+#define DAP8211R_INITIAL_RX_DEL_VAL	0
+/* Initial RGMII TX delay per hardware specification: 1 * 150ps == 0.15ns*/
+#define DAP8211R_INITIAL_TX_DEL_VAL	1
+/* Default RGMII delay: 13 * 150 == 1.95ns */
+#define DAP8211R_DEFAULT_DEL_SEL	0xD
+
+static const int dap8211r_internal_delay[] = {0, 150, 300, 450, 600, 750, 900,
+					      1050, 1200, 1350, 1500, 1650, 1800,
+					      1950, 2100, 2250};
+
+#define DAP8211R_DELAY_SIZE	ARRAY_SIZE(dap8211r_internal_delay)
+
+/**
+ * dap8211r_read_ext() - Read extended register
+ * @phydev: PHY device structure
+ * @reg: Extended register address
+ *
+ * Reads a PHY extended register using the indirect access method.
+ * The caller must hold the MDIO bus lock.
+ *
+ * Return: Register value on success, or negative error code
+ */
+static int dap8211r_read_ext(struct phy_device *phydev, u16 reg)
+{
+	int ret;
+
+	phy_lock_mdio_bus(phydev);
+	ret = __phy_write(phydev, DAP8211R_EXT_ADD, reg);
+	if (ret < 0)
+		goto out;
+
+	ret = __phy_read(phydev, DAP8211R_EXT_DATA);
+out:
+	phy_unlock_mdio_bus(phydev);
+	return ret;
+}
+
+/**
+ * dap8211r_modify_ext() - Modify extended register bits
+ * @phydev: PHY device structure
+ * @reg: Extended register address
+ * @mask: Bit mask of bits to clear
+ * @set: Bit mask of bits to set
+ *
+ * Modifies a PHY extended register using the indirect access method.
+ * New value = (old value & ~mask) | set.
+ * The caller must hold the MDIO bus lock.
+ *
+ * Return: 0 on success, or negative error code
+ */
+static int dap8211r_modify_ext(struct phy_device *phydev, u16 reg, u16 mask, u16 set)
+{
+	int ret;
+
+	phy_lock_mdio_bus(phydev);
+	ret = __phy_write(phydev, DAP8211R_EXT_ADD, reg);
+	if (ret < 0)
+		goto out;
+
+	ret = __phy_modify(phydev, DAP8211R_EXT_DATA, mask, set);
+out:
+	phy_unlock_mdio_bus(phydev);
+	return ret;
+}
+
+/**
+ * dap8211r_config_init() - Initialize PHY
+ * @phydev: PHY device structure
+ *
+ * Configures the PHY during initialization:
+ * - RGMII delays based on interface mode
+ * - Software reset to apply settings (low active, self clear)
+ *
+ * Return: 0 on success, or negative error code
+ */
+static int dap8211r_config_init(struct phy_device *phydev)
+{
+	u16 set = 0;
+	int ret, val;
+	s32 rx_internal_delay = DAP8211R_INITIAL_RX_DEL_VAL;
+	s32 tx_internal_delay = DAP8211R_INITIAL_TX_DEL_VAL;
+
+	if (!phy_interface_is_rgmii(phydev))
+		return 0;
+
+	if (phydev->interface != PHY_INTERFACE_MODE_RGMII_TXID)
+		rx_internal_delay = phy_get_internal_delay(phydev, dap8211r_internal_delay,
+							   DAP8211R_DELAY_SIZE, true);
+
+	if (phydev->interface != PHY_INTERFACE_MODE_RGMII_RXID)
+		tx_internal_delay = phy_get_internal_delay(phydev, dap8211r_internal_delay,
+							   DAP8211R_DELAY_SIZE, false);
+
+	switch (phydev->interface) {
+	case PHY_INTERFACE_MODE_RGMII:
+		if (rx_internal_delay < 0)
+			rx_internal_delay = DAP8211R_INITIAL_RX_DEL_VAL;
+
+		if (tx_internal_delay < 0)
+			tx_internal_delay = DAP8211R_INITIAL_TX_DEL_VAL;
+		break;
+	case PHY_INTERFACE_MODE_RGMII_RXID:
+		if (rx_internal_delay < 0)
+			rx_internal_delay = DAP8211R_DEFAULT_DEL_SEL;
+		break;
+	case PHY_INTERFACE_MODE_RGMII_ID:
+		if (rx_internal_delay < 0)
+			rx_internal_delay = DAP8211R_DEFAULT_DEL_SEL;
+		fallthrough;
+	case PHY_INTERFACE_MODE_RGMII_TXID:
+		if (tx_internal_delay < 0)
+			tx_internal_delay = DAP8211R_DEFAULT_DEL_SEL;
+		break;
+	default:
+		phydev_err(phydev, "Unsupported interface: %d\n",
+			   phydev->interface);
+		return -EINVAL;
+	}
+
+	set |= FIELD_PREP(DAP8211R_RGMII_RX_DEL_MASK, rx_internal_delay);
+	set |= FIELD_PREP(DAP8211R_RGMII_TX_DEL_MASK, tx_internal_delay);
+
+	ret = dap8211r_modify_ext(phydev, DAP8211R_PHY_CON, DAP8211R_PHY_SW_RST, 0);
+	if (ret)
+		return ret;
+
+	/* Wait for reset self-clear (from low active to high) */
+	ret = read_poll_timeout(dap8211r_read_ext, val,
+				(val & DAP8211R_PHY_SW_RST),
+				20, 200, false, phydev, DAP8211R_PHY_CON);
+	if (ret)
+		return ret;
+	if (val < 0)
+		return val;
+
+	ret = dap8211r_modify_ext(phydev, DAP8211R_RGMII_CON, DAP8211R_RGMII_CONFIG_MASK, set);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static struct phy_driver dap8211r_driver[] = {
+	{
+		PHY_ID_MATCH_EXACT(DAP8211R_PHY_ID),
+		.name		= "DAP8211R Gigabit Ethernet",
+		.soft_reset	= genphy_soft_reset,
+		.config_init	= dap8211r_config_init,
+		.read_status	= genphy_read_status,
+		.set_loopback	= genphy_loopback,
+		.config_aneg	= genphy_config_aneg,
+		.suspend	= genphy_suspend,
+		.resume		= genphy_resume,
+	},
+};
+module_phy_driver(dap8211r_driver);
+
+MODULE_DESCRIPTION("DAP8211R Gigabit Ethernet PHY driver");
+MODULE_AUTHOR("Artem Shimko <a.shimko.dev@gmail.com>");
+MODULE_LICENSE("GPL");
+
+static const struct mdio_device_id __maybe_unused dap8211r_tb[] = {
+	{ DAP8211R_PHY_ID, DAP8211R_PHY_ID_MASK },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(mdio, dap8211r_tb);
+

gemini-3.1-pro-preview

							input: 6163
							output: 19
							thoughts: 1131

**Assessing the Fuzzability of the DAP8211R PHY Driver**

Okay, so we have a new PHY driver here for the DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY. The patch is pretty straightforward: documentation, Kconfig, Makefile, and the driver itself (`dap8211r.c`). The driver implements the standard PHY initialization, read/modify functions and utilizes some generic PHY functions.

My initial thought is, can we actually reach this in a virtualized environment? PHY drivers, as we know, are probed via the MDIO bus. QEMU *might* have MDIO buses on some network devices, allowing PHY probing based on device tree configurations or driver instantiation. However, specific PHY drivers usually probe only if the hardware reports their specific ID (in this case `0x0008011B`) or if the device tree explicitly lists a compatible string.

Can syzkaller fuzz this? That's the key question. Can it instantiate the driver? Syzkaller has some network capabilities with `syz_genetlink_get_family` and such, but for PHYs it hinges on the MDIO bus. Can userspace somehow *directly* instantiate a PHY driver through sysfs or netlink? No, normally PHYs are probed via MDIO scanning.

So, for syzkaller to reach this, we'd need an emulated MDIO bus, or perhaps a virtual driver. Does syzkaller have this? I know it can inject MDIO frames in the right circumstances. It doesn't seem to, but maybe through the right mechanisms. I'm thinking of something like `macsec` or `dummy` but those don't have MDIO.

Let's think about the driver itself. `dap8211r_config_init` is called when the PHY is initialized. It's the entry point. Is this worth fuzzing? PHY drivers are often very hardware-specific, which makes reaching them difficult without emulating the exact hardware.

Let's think about the instructions for determining if a patch is worth fuzzing. The instructions mention that code in vendor-specific PCIe switch, SmartNIC, or GPU drivers is not worth fuzzing if they require physical PCIe hardware cards not emulated in standard QEMU. This seems similar: it's a vendor-specific Ethernet PHY driver. It requires an MDIO bus and the specific PHY hardware, or at least a matching device tree node. Can we reach it in standard QEMU? Probably not. QEMU emulates generic PHYs, but not this specific one, DAP8211R. Also, the driver is very simple; mostly register reads and writes.

I'm thinking, is there *any* way to trigger this? And, if we can't easily reach it, we should mark it as not worth fuzzing. I need to double-check if syzkaller has some advanced MDIO injection tricks. I'll search syzkaller for `mdio`.

The prompt specifically says to avoid code paths that are impossible to reach in virtualized environments. PHY drivers are generally in that category, unless there's a specific emulation or a userspace-controllable software MDIO bus. Is there a software MDIO bus? I'll check the `drivers/net/phy/` directory for something like `mdio-mockup` or `mdio-gpio` that could be instantiated from userspace. Even if one exists, the driver itself is extremely simple.

Okay, I'm going to mark this as WorthFuzzing=false. It's a vendor-specific PHY driver that requires either physical hardware (or specific device tree configuration) or a very specific QEMU emulation. Standard QEMU, I'm pretty sure, won't cut it. I need to go over the virtual MDIO drivers.

{
  "Expression": "mdio.*mockup"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

							input: 8151
							output: 24
							thoughts: 51

Okay, here's my take on those thoughts, tailored for an expert audience:

**Investigating Userspace MDIO Driver Interaction**

Alright, time to dive in. I need to figure out if there's a mechanism in the current kernel that allows for user-space instantiation of an `mdio` driver. My immediate focus will be on the typical driver locations, so I'll be searching through `drivers/net/phy/` and `drivers/net/mdio/`. I'm looking for anything that suggests a means for user-space programs to interface with or even directly manage an MDIO PHY. Essentially, is there a user-space API built on top of the MDIO bus code? I need to understand if the kernel provides a framework for userland to register and control its own MDIO drivers and manage MDIO devices directly, rather than solely through the standard network interface setup.

{
  "Dir": "drivers/net/mdio"
}

{
  "Files": [
    "acpi_mdio.c",
    "fwnode_mdio.c",
    "mdio-airoha.c",
    "mdio-aspeed.c",
    "mdio-bcm-iproc.c",
    "mdio-bcm-unimac.c",
    "mdio-bitbang.c",
    "mdio-cavium.c",
    "mdio-cavium.h",
    "mdio-gpio.c",
    "mdio-hisi-femac.c",
    "mdio-i2c.c",
    "mdio-ipq4019.c",
    "mdio-ipq8064.c",
    "mdio-moxart.c",
    "mdio-mscc-miim.c",
    "mdio-mux-bcm-iproc.c",
    "mdio-mux-bcm6368.c",
    "mdio-mux-gpio.c",
    "mdio-mux-meson-g12a.c",
    "mdio-mux-meson-gxl.c",
    "mdio-mux-mmioreg.c",
    "mdio-mux-multiplexer.c",
    "mdio-mux.c",
    "mdio-mvusb.c",
    "mdio-octeon.c",
    "mdio-pic64hpsc.c",
    "mdio-realtek-rtl9300.c",
    "mdio-regmap.c",
    "mdio-sun4i.c",
    "mdio-thunder.c",
    "mdio-xgene.c",
    "of_mdio.c"
  ],
  "Subdirs": null
}

gemini-3.1-pro-preview

							input: 8815
							output: 19
							thoughts: 79

Okay, let's break this down.

**Potential for Syzkaller Integration: USB-based MDIO Adapter**

Right, so I'm thinking about MDIO drivers here. Specifically, I'm seeing references to `mdio-gpio.c`, `mdio-i2c.c`, and then this interesting one: `mdio-mvusb.c`.  A USB to MDIO adapter... that's the Marvell USB MDIO Adapter, if I recall correctly. Now my mind immediately jumps to Syzkaller. If we could emulate this USB gadget, that opens up a whole new attack surface for fuzzing. This could be a significant discovery. The implications are potentially huge for testing this kind of hardware. So, where to start? Let's dive into `mdio-mvusb.c` and see what makes it tick.

{
  "Expression": "Marvell USB MDIO"
}

{
  "Output": "drivers/net/mdio/mdio-mvusb.c=111=MODULE_AUTHOR(\"Tobias Waldekranz \u003ctobias@waldekranz.com\u003e\");\ndrivers/net/mdio/mdio-mvusb.c:112:MODULE_DESCRIPTION(\"Marvell USB MDIO Adapter\");\ndrivers/net/mdio/mdio-mvusb.c-113-MODULE_LICENSE(\"GPL\");\n"
}

gemini-3.1-pro-preview

							input: 9205
							output: 24
							thoughts: 222

**Emulating the Marvell USB MDIO Adapter in Syzkaller: A Feasibility Analysis**

Okay, so I'm thinking about how syzkaller could possibly emulate this Marvell USB MDIO adapter. If we could get it to register an MDIO bus, that would be a huge step. But then the question becomes, how does it instantiate the specific PHY? My understanding is that the PHY is typically discovered through probing the MDIO bus. If the emulated USB device *could* somehow respond to MDIO reads on those crucial PHY ID registers (registers 2 and 3, to be precise), and returned `0x0008011B`, the kernel would happily load and bind the `dap8211r` driver. Bingo!

But that brings up the big question: does syzkaller's USB fuzzer even know how to respond to MDIO read requests when dealing with the Marvell USB protocol? That's the crux of it, right? I'm assuming the Marvell USB MDIO adapter protocol is relatively straightforward. Syzkaller's USB fuzzer generates responses randomly, in general. So there's always a theoretical possibility of it accidentally returning the *correct* PHY ID, but the probability of it randomly hitting *exactly* `0x0008011B` in the *right* registers is vanishingly small. We'd essentially be talking about winning the lottery. Unless, of course, there are existing syzlang descriptions specifically for this protocol, which would make the chance of generating that magic number much higher.

Right, so I need to check if there are any syzkaller descriptions, or any information at all, that deal with `mdio` or `mvusb`. That's the next step in my investigation.

{
  "Expression": "mdio",
  "PathPrefix": "sys/"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

							input: 9845
							output: 132
							thoughts: 887

**Fuzzing Decision for the DAP8211R PHY Driver**

Okay, first things first, I need to remember that `grepper` is off-limits for `sys/` files, specifically the syzkaller language descriptions. I need to use `read-syz-spec` or `syz-grepper` for those, but neither of those tools is in my current arsenal. So, checking syzlang descriptions is out.

Even if I *could* get at the syzlang, this driver itself looks incredibly simple. I see the code, and it's just a sequence of MDIO reads and writes. It's essentially initializing a piece of hardware. No complex logic, no Netlink interfaces, no sysfs attributes, nothing that would be interesting from a fuzzing perspective. Fuzzing this thing would basically boil down to randomly returning values from the `dap8211r_read_ext` function. Is that really worth the effort?

Now, let's think about the "WorthFuzzing" criteria. My internal rule says, "Return WorthFuzzing=false if the patch only contains...Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers...that require physical PCIe hardware cards not emulated in standard QEMU". This DAP8211R driver is a vendor-specific Ethernet PHY. It *requires* the physical DAP8211R hardware. Theoretically, I could *maybe* reach it with a USB-MDIO adapter and random USB responses, but that's a long shot and not the intended setup. It's impractical and not what this fuzzer is designed for. Plus, it's a vendor-specific hardware driver, which is another mark against it.

Okay, let's consider other avenues to reach it. Device tree? Syzkaller doesn't typically inject arbitrary device trees at runtime (barring overlays, but that's restricted). Nope. That's not a path.

So, here's my conclusion: This is a vendor-specific Ethernet PHY driver that requires physical hardware not emulated in standard QEMU. Its logic is extremely trivial—just a register initialization sequence. Therefore, it's not worth fuzzing. I'm going to document the reasoning concisely as follows: "This patch introduces a new vendor-specific Ethernet PHY driver for the DAPU Telecom DAP8211R(I). PHY drivers require specific physical hardware to be present on an MDIO bus (or specific device tree configurations and hardware emulation not present in standard QEMU) to be probed and executed. Furthermore, the driver only contains trivial hardware initialization sequences (register reads/writes) and does not expose any complex software interfaces, making it unsuitable and unreachable for fuzzing in a virtualized environment."

Just to be absolutely certain, I'll quickly check the other modified files to make sure nothing else sneaky is going on. I'll look at `Documentation/devicetree/bindings/net/dapu,dap8211r.yaml`, `Documentation/devicetree/bindings/vendor-prefixes.yaml`, `drivers/net/phy/Kconfig`, `drivers/net/phy/Makefile`, and `drivers/net/phy/dap8211r.c`. Okay, it's all directly related to this one PHY driver.

Alright, I'm setting `WorthFuzzing=false`.

{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "This patch introduces a new vendor-specific Ethernet PHY driver for the DAPU Telecom DAP8211R(I). PHY drivers require specific physical hardware to be present on an MDIO bus (or specific device tree configurations and hardware emulation not present in standard QEMU) to be probed and executed. Furthermore, the driver only contains trivial hardware initialization sequences (register reads/writes) and does not expose any complex software interfaces, making it unsuitable and unreachable for fuzzing in a virtualized environment.",
  "WorthFuzzing": false
}

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "This patch introduces a new vendor-specific Ethernet PHY driver for the DAPU Telecom DAP8211R(I). PHY drivers require specific physical hardware to be present on an MDIO bus (or specific device tree configurations and hardware emulation not present in standard QEMU) to be probed and executed. Furthermore, the driver only contains trivial hardware initialization sequences (register reads/writes) and does not expose any complex software interfaces, making it unsuitable and unreachable for fuzzing in a virtualized environment.",
  "WorthFuzzing": false
}

LLM Calls Summary:
Total Calls	Total Tokens	Avg Tokens	Total Duration (Seconds)	Avg Duration (Seconds)

Tool Calls Summary:
Total Calls	Total Duration (Seconds)	Avg Duration (Seconds)