AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "KMSANReasoning": "",
  "NeedsKMSAN": false,
  "Reasoning": "The patch modifies chip reset logic and timing in rtl8365mb_reset_chip() within the Realtek RTL8365MB DSA switch driver (drivers/net/dsa/realtek/rtl8365mb_main.c). This driver targets physical Realtek switch ASICs attached via SMI or MDIO buses defined via Device Tree (OF), which are not present or emulated in standard virtualized environments (QEMU/GCE) on amd64. The modified code is structurally unreachable.",
  "WorthFuzzing": false
}

null

{
  "PatchDiff": "commit 5414c155414dc30fac562e42a68152c64dff3aa3\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Wed Sep 9 12:56:30 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/dsa/realtek/rtl8365mb_main.c b/drivers/net/dsa/realtek/rtl8365mb_main.c\nindex f8220d832e460..19e2cf605d4e6 100644\n--- a/drivers/net/dsa/realtek/rtl8365mb_main.c\n+++ b/drivers/net/dsa/realtek/rtl8365mb_main.c\n@@ -136,6 +136,9 @@\n #define RTL8365MB_CHIP_RESET_SW_MASK\t0x0002\n #define RTL8365MB_CHIP_RESET_HW_MASK\t0x0001\n \n+/* Time the chip needs to complete a reset, per Realtek documentation */\n+#define RTL8365MB_CHIP_RESET_TIME_MS\t1000\n+\n /* Interrupt polarity register */\n #define RTL8365MB_INTR_POLARITY_REG\t0x1100\n #define   RTL8365MB_INTR_POLARITY_MASK\t0x0001\n@@ -2981,17 +2984,27 @@ static int rtl8365mb_switch_init(struct realtek_priv *priv)\n static int rtl8365mb_reset_chip(struct realtek_priv *priv)\n {\n \tu32 val;\n+\tint ret;\n \n \tpriv-\u003ewrite_reg_noack(priv, RTL8365MB_CHIP_RESET_REG,\n \t\t\t      FIELD_PREP(RTL8365MB_CHIP_RESET_HW_MASK, 1));\n \n-\t/* Realtek documentation says the chip needs 1 second to reset. Sleep\n-\t * for 100 ms before accessing any registers to prevent ACK timeouts.\n+\t/* Realtek documentation says the chip needs 1 second to reset. The\n+\t * reset bit clears before that time is up, and it only reports that\n+\t * the register block is back, not that the chip has finished its\n+\t * internal bring-up, so wait out the documented time before touching\n+\t * anything.\n \t */\n-\tmsleep(100);\n-\treturn regmap_read_poll_timeout(priv-\u003emap, RTL8365MB_CHIP_RESET_REG, val,\n-\t\t\t\t\t!(val \u0026 RTL8365MB_CHIP_RESET_HW_MASK),\n-\t\t\t\t\t20000, 1e6);\n+\tmsleep(RTL8365MB_CHIP_RESET_TIME_MS);\n+\n+\tret = regmap_read(priv-\u003emap, RTL8365MB_CHIP_RESET_REG, \u0026val);\n+\tif (ret)\n+\t\treturn ret;\n+\n+\tif (val \u0026 RTL8365MB_CHIP_RESET_HW_MASK)\n+\t\treturn -ETIMEDOUT;\n+\n+\treturn 0;\n }\n \n static int rtl8365mb_setup(struct dsa_switch *ds)\n"
}

core

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch modifies chip reset logic and timing in rtl8365mb_reset_chip() within the Realtek RTL8365MB DSA switch driver (drivers/net/dsa/realtek/rtl8365mb_main.c). This driver targets physical Realtek switch ASICs attached via SMI or MDIO buses defined via Device Tree (OF), which are not present or emulated in standard virtualized environments (QEMU/GCE) on amd64. The modified code is structurally unreachable.",
  "WorthFuzzing": false
}

You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.

================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.

- REACHABILITY IS THE PRIMARY GATE:
  Fuzzing can only discover bugs in code that can actually execute in standard virtualized
  environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
  If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
  regardless of whether it adds assertions or complex logic.

- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
  Patch authors routinely label changes as "cleanups", "refactorings", or state
  "No functional change intended". Do NOT take these claims at face value.
  Code refactorings that rearrange logic, introduce helper functions, or alter state management
  in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
  If reachable executable code is modified or refactored, it MUST be fuzzed.

- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
  When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
  BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
  Even if the author believes the invariant always holds, fuzzing is essential to verify whether
  an unusual sequence of operations can violate it.

================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:

- Non-kernel and non-executable changes:
  * Modifications to Documentation/, comments, or spelling fixes.
  * User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
    that do not affect the compiled kernel image (vmlinux) or kernel modules.
  * Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
    that do not alter control flow or data structures.
  * Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
  * Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
    ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
  * Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
    physical PCI hot-unplug or manual sysfs driver unbinding.
  * Code paths exclusive to architectures other than the target architecture.

================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
  * Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
    BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
  * Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
  * Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
  * Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).

================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:

- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
  Do NOT list generic, ubiquitous functions called by almost every program in the corpus
  (including, but not limited to: general memory allocators and deallocators, page fault
  and trap handlers, or core synchronization primitives; this is not an exhaustive list).
  Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
  which severely dilutes fuzzing effort away from the actual changes.

- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
  List functions that specifically implement the logic being added or altered, or direct API entrypoints
  for the subsystem feature under review.

- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
  Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
  distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
  If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
  functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).

================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

Target architecture: amd64

For your convenience, here is the diff of the changes:
commit 5414c155414dc30fac562e42a68152c64dff3aa3
Author: syz-cluster <triage@syzkaller.com>
Date:   Wed Sep 9 12:56:30 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/dsa/realtek/rtl8365mb_main.c b/drivers/net/dsa/realtek/rtl8365mb_main.c
index f8220d832e460..19e2cf605d4e6 100644
--- a/drivers/net/dsa/realtek/rtl8365mb_main.c
+++ b/drivers/net/dsa/realtek/rtl8365mb_main.c
@@ -136,6 +136,9 @@
 #define RTL8365MB_CHIP_RESET_SW_MASK	0x0002
 #define RTL8365MB_CHIP_RESET_HW_MASK	0x0001
 
+/* Time the chip needs to complete a reset, per Realtek documentation */
+#define RTL8365MB_CHIP_RESET_TIME_MS	1000
+
 /* Interrupt polarity register */
 #define RTL8365MB_INTR_POLARITY_REG	0x1100
 #define   RTL8365MB_INTR_POLARITY_MASK	0x0001
@@ -2981,17 +2984,27 @@ static int rtl8365mb_switch_init(struct realtek_priv *priv)
 static int rtl8365mb_reset_chip(struct realtek_priv *priv)
 {
 	u32 val;
+	int ret;
 
 	priv->write_reg_noack(priv, RTL8365MB_CHIP_RESET_REG,
 			      FIELD_PREP(RTL8365MB_CHIP_RESET_HW_MASK, 1));
 
-	/* Realtek documentation says the chip needs 1 second to reset. Sleep
-	 * for 100 ms before accessing any registers to prevent ACK timeouts.
+	/* Realtek documentation says the chip needs 1 second to reset. The
+	 * reset bit clears before that time is up, and it only reports that
+	 * the register block is back, not that the chip has finished its
+	 * internal bring-up, so wait out the documented time before touching
+	 * anything.
 	 */
-	msleep(100);
-	return regmap_read_poll_timeout(priv->map, RTL8365MB_CHIP_RESET_REG, val,
-					!(val & RTL8365MB_CHIP_RESET_HW_MASK),
-					20000, 1e6);
+	msleep(RTL8365MB_CHIP_RESET_TIME_MS);
+
+	ret = regmap_read(priv->map, RTL8365MB_CHIP_RESET_REG, &val);
+	if (ret)
+		return ret;
+
+	if (val & RTL8365MB_CHIP_RESET_HW_MASK)
+		return -ETIMEDOUT;
+
+	return 0;
 }
 
 static int rtl8365mb_setup(struct dsa_switch *ds)

gemini-3.7-flash

null

null

							input: 3430
							output: 22
							thoughts: 133
						

**Analyzing a Realtek RTL8365MB DSA Driver Patch**

Okay, so the patch I'm looking at specifically targets `drivers/net/dsa/realtek/rtl8365mb_main.c`. That immediately tells me this involves the Realtek RTL8365MB, and that it's interacting with the Data Switching Architecture (DSA) within the networking stack. My first move is to verify what's being modified. Ah, it's `rtl8365mb_reset_chip()` in that same file. This driver must handle the reset functionality, which is pretty fundamental.

Now, it's time to dig deeper. I need to understand the context of this driver. Is it for a commonly used switch? Or is it part of some more specialized hardware? Given that it's a DSA switch driver for the RTL8365MB, I have a pretty good starting point. I want to determine the reachability and the overall structure. Is this code actively used, or is it potentially dead code?

To get a clearer picture, I'll start by grepping the code for usage and configurations, and read the relevant files – Kconfig, probably. It's time to dive into the source and see where this driver fits in the bigger picture.

{
  "Expression": "config NET_DSA_REALTEK"
}

{
  "Output": "drivers/net/dsa/realtek/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/net/dsa/realtek/Kconfig:2:menuconfig NET_DSA_REALTEK\ndrivers/net/dsa/realtek/Kconfig-3-\ttristate \"Realtek Ethernet switch family support\"\n--\ndrivers/net/dsa/realtek/Kconfig=16=if NET_DSA_REALTEK\ndrivers/net/dsa/realtek/Kconfig-17-\ndrivers/net/dsa/realtek/Kconfig:18:config NET_DSA_REALTEK_MDIO\ndrivers/net/dsa/realtek/Kconfig-19-\tbool \"Realtek MDIO interface support\"\n--\ndrivers/net/dsa/realtek/Kconfig-24-\ndrivers/net/dsa/realtek/Kconfig:25:config NET_DSA_REALTEK_SMI\ndrivers/net/dsa/realtek/Kconfig-26-\tbool \"Realtek SMI interface support\"\n--\ndrivers/net/dsa/realtek/Kconfig-31-\ndrivers/net/dsa/realtek/Kconfig:32:config NET_DSA_REALTEK_RTL8365MB\ndrivers/net/dsa/realtek/Kconfig-33-\ttristate \"Realtek RTL8365MB switch driver\"\n--\ndrivers/net/dsa/realtek/Kconfig-38-\ndrivers/net/dsa/realtek/Kconfig:39:config NET_DSA_REALTEK_RTL8366RB\ndrivers/net/dsa/realtek/Kconfig-40-\ttristate \"Realtek RTL8366RB switch driver\"\n--\ndrivers/net/dsa/realtek/Kconfig-45-\ndrivers/net/dsa/realtek/Kconfig:46:config NET_DSA_REALTEK_RTL8366RB_LEDS\ndrivers/net/dsa/realtek/Kconfig-47-\tbool\n"
}

gemini-3.7-flash

null

null

							input: 4370
							output: 38
							thoughts: 18
						

Here's a summary of my thought process, as if I were analyzing that Kconfig file:

**Diving into the Realtek DSA Kconfig**

Alright, let's crack open `drivers/net/dsa/realtek/Kconfig`. This is where the magic happens – or at least, the configuration of the Realtek DSA (Distributed Switch Architecture) driver within the kernel. I need to understand what features are being controlled here, what options are available to us, and how we can best leverage them for specific use cases. I'm immediately looking for:

*   **Dependencies:** What other kernel components or options does this depend on? Are there specific network subsystems or hardware configurations it requires? Identifying these dependencies is crucial for a smooth integration and understanding potential conflicts.
*   **Feature Control:** What specific Realtek switch features are exposed through this Kconfig file? Are we talking about basic things like port configuration (speed, duplex), VLAN support, QoS capabilities, or more advanced features like traffic shaping and mirroring? The granularity of control is key.
*   **Default Values:** What are the default settings for each option? Knowing the defaults provides context, particularly when investigating potential issues or customizing the driver for a specific board or network setup.
*   **Help Text:** Hopefully, the Kconfig file has good, descriptive help text. This is a vital resource for anyone trying to understand the purpose of each option. Clear and concise explanations save a lot of time and guesswork.
*   **Conditional Compilation:** I'll be looking for any `if` statements or other conditional logic. This will show how options are enabled or disabled based on other kernel configurations or hardware constraints. This is particularly important for understanding how different Realtek switch models or driver versions are handled.
*   **Integration Points:** I'll be glancing for any references to other Kconfig files or driver components. This may help in identifying potential integration points, interactions with other network subsystems or dependencies on other Realtek components.

Essentially, I need to get a clear picture of the configuration space for this driver and how it fits into the overall network stack. The Kconfig file is the roadmap. Now, let's get reading and understanding.

{
  "File": "drivers/net/dsa/realtek/Kconfig",
  "FirstLine": 1,
  "LineCount": 60
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0-only\n   2:\tmenuconfig NET_DSA_REALTEK\n   3:\t\ttristate \"Realtek Ethernet switch family support\"\n   4:\t\tdepends on NET_DSA\n   5:\t\tselect FIXED_PHY\n   6:\t\tselect IRQ_DOMAIN\n   7:\t\tselect REALTEK_PHY\n   8:\t\tselect REGMAP\n   9:\t\thelp\n  10:\t\t  Select to enable support for Realtek Ethernet switch chips.\n  11:\t\n  12:\t\t  Note that at least one interface driver must be enabled for the\n  13:\t\t  subdrivers to be loaded. Moreover, an interface driver cannot achieve\n  14:\t\t  anything without at least one subdriver enabled.\n  15:\t\n  16:\tif NET_DSA_REALTEK\n  17:\t\n  18:\tconfig NET_DSA_REALTEK_MDIO\n  19:\t\tbool \"Realtek MDIO interface support\"\n  20:\t\tdepends on OF\n  21:\t\thelp\n  22:\t\t  Select to enable support for registering switches configured\n  23:\t\t  through MDIO.\n  24:\t\n  25:\tconfig NET_DSA_REALTEK_SMI\n  26:\t\tbool \"Realtek SMI interface support\"\n  27:\t\tdepends on OF\n  28:\t\thelp\n  29:\t\t  Select to enable support for registering switches connected\n  30:\t\t  through SMI.\n  31:\t\n  32:\tconfig NET_DSA_REALTEK_RTL8365MB\n  33:\t\ttristate \"Realtek RTL8365MB switch driver\"\n  34:\t\tdepends on NET_DSA_REALTEK_SMI || NET_DSA_REALTEK_MDIO\n  35:\t\tselect NET_DSA_TAG_RTL8_4\n  36:\t\thelp\n  37:\t\t  Select to enable support for Realtek RTL8365MB-VC and RTL8367S.\n  38:\t\n  39:\tconfig NET_DSA_REALTEK_RTL8366RB\n  40:\t\ttristate \"Realtek RTL8366RB switch driver\"\n  41:\t\tdepends on NET_DSA_REALTEK_SMI || NET_DSA_REALTEK_MDIO\n  42:\t\tselect NET_DSA_TAG_RTL4_A\n  43:\t\thelp\n  44:\t\t  Select to enable support for Realtek RTL8366RB.\n  45:\t\n  46:\tconfig NET_DSA_REALTEK_RTL8366RB_LEDS\n  47:\t\tbool\n  48:\t\tdepends on (LEDS_CLASS=y || LEDS_CLASS=NET_DSA_REALTEK_RTL8366RB)\n  49:\t\tdepends on NET_DSA_REALTEK_RTL8366RB\n  50:\t\tdefault NET_DSA_REALTEK_RTL8366RB\n  51:\t\n  52:\tendif\n"
}

gemini-3.7-flash

null

null

							input: 5647
							output: 27
							thoughts: 61
						

**Investigating the RTL8365MB Driver**

Okay, let's dive into this. I need to understand how the `rtl8365mb_main.c` driver is initialized and probed. My primary goal is to determine if its operation hinges on particular physical hardware configurations, perhaps requiring Device Tree (OF), the MDIO bus, or even the SMI bus. My immediate course of action is to explore the relevant files within the `drivers/net/dsa/realtek/` directory. That seems like the logical starting point for understanding the device's interaction with the system.

{
  "Dir": "drivers/net/dsa/realtek"
}

{
  "Files": [
    "realtek-mdio.c",
    "realtek-mdio.h",
    "realtek-smi.c",
    "realtek-smi.h",
    "realtek.h",
    "rtl8365mb_l2.c",
    "rtl8365mb_l2.h",
    "rtl8365mb_main.c",
    "rtl8365mb_table.c",
    "rtl8365mb_table.h",
    "rtl8365mb_vlan.c",
    "rtl8365mb_vlan.h",
    "rtl8366-core.c",
    "rtl8366rb-leds.c",
    "rtl8366rb.c",
    "rtl8366rb.h",
    "rtl83xx.c",
    "rtl83xx.h"
  ],
  "Subdirs": null
}

gemini-3.7-flash

null

null

							input: 6082
							output: 35
							thoughts: 37
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Analyzing the Realtek Switch Driver Probe Functions**

Alright, let's dive into this Realtek driver code. I need to understand how these switch devices are being detected and initialized. Specifically, I'm going to focus on the `rtl8365mb_probe`, `realtek_smi_probe`, and `realtek_mdio_probe` functions. I'm assuming that these are the entry points for different Realtek switch chipsets, or perhaps different interfaces like SMI or MDIO, but I need to confirm that. My immediate goal is to understand the control flow. What checks are they performing? What resources are they allocating and initializing? Are they relying on platform-specific data, or are there more generic methods at play? I'll probably look for the matching `remove` functions shortly after this so I have a picture of the lifecycle. I expect to be able to map a particular switch to each of these, but I wonder if there are overlapping functions, and how they interact. Are there any common error handling patterns that I can leverage in my current project? Ultimately, I want to form a complete mental model of how these Realtek switch interfaces are detected and configured. Let's start with the first one…

{
  "Expression": "rtl8365mb",
  "PathPrefix": "drivers/net/dsa/realtek"
}

{
  "Output": "\nFull output is too long, showing 500 out of 1683 lines.\nUse more precise expression if possible.\n\ndrivers/net/dsa/realtek/Makefile=17=endif\ndrivers/net/dsa/realtek/Makefile:18:obj-$(CONFIG_NET_DSA_REALTEK_RTL8365MB) += rtl8365mb.o\ndrivers/net/dsa/realtek/Makefile:19:rtl8365mb-objs := rtl8365mb_main.o \\\ndrivers/net/dsa/realtek/Makefile:20:\t\t  rtl8365mb_table.o \\\ndrivers/net/dsa/realtek/Makefile:21:\t\t  rtl8365mb_vlan.o \\\ndrivers/net/dsa/realtek/Makefile:22:\t\t  rtl8365mb_l2.o \\\ndrivers/net/dsa/realtek/Makefile:23:# end of rtl8365mb-objs\n--\ndrivers/net/dsa/realtek/realtek.h=193=extern const struct realtek_variant rtl8366rb_variant;\ndrivers/net/dsa/realtek/realtek.h:194:extern const struct realtek_variant rtl8365mb_variant;\ndrivers/net/dsa/realtek/realtek.h-195-\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-1-// SPDX-License-Identifier: GPL-2.0\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:2:/* Forwarding and multicast database interface for the rtl8365mb switch family\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-3- *\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-8-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:9:#include \"rtl8365mb_l2.h\"\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:10:#include \"rtl8365mb_table.h\"\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-11-#include \u003clinux/regmap.h\u003e\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-91-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:92:struct rtl8365mb_l2_uc_key {\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-93-\tu8 mac_addr[ETH_ALEN];\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-99-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:100:struct rtl8365mb_l2_uc {\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:101:\tstruct rtl8365mb_l2_uc_key key;\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-102-\tu8 port;\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-113-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:114:struct rtl8365mb_l2_mc_key {\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-115-\tu8 mac_addr[ETH_ALEN];\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-122-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:123:struct rtl8365mb_l2_mc {\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:124:\tstruct rtl8365mb_l2_mc_key key;\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-125-\tu16 member;\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-133-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:134:static void rtl8365mb_l2_data_to_uc(const u16 *data, struct rtl8365mb_l2_uc *uc)\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-135-{\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-163-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:164:static void rtl8365mb_l2_uc_to_data(const struct rtl8365mb_l2_uc *uc, u16 *data)\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-165-{\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-202-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:203:static void rtl8365mb_l2_data_to_mc(const u16 *data, struct rtl8365mb_l2_mc *mc)\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-204-{\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-230-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:231:static void rtl8365mb_l2_mc_to_data(const struct rtl8365mb_l2_mc *mc, u16 *data)\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-232-{\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-261-/*\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:262: * rtl8365mb_l2_get_next_uc() - get the next Unicast L2 entry\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-263- * @priv: realtek_priv pointer\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-281- **/\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:282:int rtl8365mb_l2_get_next_uc(struct realtek_priv *priv, u16 *addr, int port,\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-283-\t\t\t     struct realtek_fdb_entry *entry)\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-285-\tu16 data[RTL8365MB_L2_ENTRY_SIZE] = { 0 };\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:286:\tstruct rtl8365mb_l2_uc uc;\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-287-\tint ret;\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-288-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:289:\tret = rtl8365mb_table_query(priv, RTL8365MB_TABLE_L2,\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-290-\t\t\t\t    RTL8365MB_TABLE_OP_READ, addr,\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-295-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:296:\trtl8365mb_l2_data_to_uc(data, \u0026uc);\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-297-\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-304-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:305:int rtl8365mb_l2_add_uc(struct realtek_priv *priv, int port,\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-306-\t\t\tconst unsigned char mac_addr[static ETH_ALEN],\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-309-\tu16 data[RTL8365MB_L2_ENTRY_SIZE] = { 0 };\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:310:\tstruct rtl8365mb_l2_uc uc = { 0 };\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-311-\tu16 addr;\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-328-\tuc.age = 1;\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:329:\trtl8365mb_l2_uc_to_data(\u0026uc, data);\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-330-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-331-\t/* add the new entry or update an existing one */\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:332:\tret = rtl8365mb_table_query(priv, RTL8365MB_TABLE_L2,\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-333-\t\t\t\t    RTL8365MB_TABLE_OP_WRITE, \u0026addr,\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-344-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:345:int rtl8365mb_l2_del_uc(struct realtek_priv *priv, int port,\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-346-\t\t\tconst unsigned char mac_addr[static ETH_ALEN],\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-349-\tu16 data[RTL8365MB_L2_ENTRY_SIZE] = { 0 };\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:350:\tstruct rtl8365mb_l2_uc uc = { 0 };\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-351-\tu16 addr;\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-360-\tuc.age = 0;\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:361:\trtl8365mb_l2_uc_to_data(\u0026uc, data);\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-362-\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-367-\t */\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:368:\tret = rtl8365mb_table_query(priv, RTL8365MB_TABLE_L2,\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-369-\t\t\t\t    RTL8365MB_TABLE_OP_WRITE, \u0026addr,\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-383-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:384:int rtl8365mb_l2_flush(struct realtek_priv *priv, int port, u16 vid)\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-385-{\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-448-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:449:int rtl8365mb_l2_add_mc(struct realtek_priv *priv, int port,\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-450-\t\t\tconst unsigned char mac_addr[static ETH_ALEN],\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-453-\tu16 data[RTL8365MB_L2_ENTRY_SIZE] = { 0 };\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:454:\tstruct rtl8365mb_l2_mc mc = { 0 };\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-455-\tu16 addr;\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-465-\tmc.is_static = 1;\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:466:\trtl8365mb_l2_mc_to_data(\u0026mc, data);\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-467-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-468-\t/* First look for an existing entry (to get existing port members) */\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:469:\tret = rtl8365mb_table_query(priv, RTL8365MB_TABLE_L2,\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-470-\t\t\t\t    RTL8365MB_TABLE_OP_READ, \u0026addr,\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-474-\t\t/* There is already an entry... */\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:475:\t\trtl8365mb_l2_data_to_mc(data, \u0026mc);\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-476-\t\tdev_dbg(priv-\u003edev,\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-489-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:490:\t\trtl8365mb_l2_mc_to_data(\u0026mc, data);\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-491-\t} else if (ret == -ENOENT) {\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-507-\t/* add the new entry or update an existing one */\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:508:\tret = rtl8365mb_table_query(priv, RTL8365MB_TABLE_L2,\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-509-\t\t\t\t    RTL8365MB_TABLE_OP_WRITE, \u0026addr,\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-519-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:520:int rtl8365mb_l2_del_mc(struct realtek_priv *priv, int port,\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-521-\t\t\tconst unsigned char mac_addr[static ETH_ALEN],\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-524-\tu16 data[RTL8365MB_L2_ENTRY_SIZE] = { 0 };\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:525:\tstruct rtl8365mb_l2_mc mc = { 0 };\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-526-\tu16 addr;\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-531-\tmc.key.ivl = true;\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:532:\trtl8365mb_l2_mc_to_data(\u0026mc, data);\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-533-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-534-\t/* First look for an existing entry (to get existing port members) */\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:535:\tret = rtl8365mb_table_query(priv, RTL8365MB_TABLE_L2,\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-536-\t\t\t\t    RTL8365MB_TABLE_OP_READ, \u0026addr,\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-549-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:550:\trtl8365mb_l2_data_to_mc(data, \u0026mc);\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-551-\tdev_dbg(priv-\u003edev,\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-567-\t}\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:568:\trtl8365mb_l2_mc_to_data(\u0026mc, data);\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-569-\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-570-\t/* update the existing entry. */\ndrivers/net/dsa/realtek/rtl8365mb_l2.c:571:\tret = rtl8365mb_table_query(priv, RTL8365MB_TABLE_L2,\ndrivers/net/dsa/realtek/rtl8365mb_l2.c-572-\t\t\t\t    RTL8365MB_TABLE_OP_WRITE, \u0026addr,\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.h-1-/* SPDX-License-Identifier: GPL-2.0 */\ndrivers/net/dsa/realtek/rtl8365mb_l2.h:2:/* Forwarding and multicast database interface for the rtl8365mb switch family\ndrivers/net/dsa/realtek/rtl8365mb_l2.h-3- *\n--\ndrivers/net/dsa/realtek/rtl8365mb_l2.h-14-\ndrivers/net/dsa/realtek/rtl8365mb_l2.h:15:int rtl8365mb_l2_get_next_uc(struct realtek_priv *priv, u16 *addr, int port,\ndrivers/net/dsa/realtek/rtl8365mb_l2.h-16-\t\t\t     struct realtek_fdb_entry *entry);\ndrivers/net/dsa/realtek/rtl8365mb_l2.h:17:int rtl8365mb_l2_add_uc(struct realtek_priv *priv, int port,\ndrivers/net/dsa/realtek/rtl8365mb_l2.h-18-\t\t\tconst unsigned char addr[static ETH_ALEN],\ndrivers/net/dsa/realtek/rtl8365mb_l2.h-19-\t\t\tu16 efid, u16 vid);\ndrivers/net/dsa/realtek/rtl8365mb_l2.h:20:int rtl8365mb_l2_del_uc(struct realtek_priv *priv, int port,\ndrivers/net/dsa/realtek/rtl8365mb_l2.h-21-\t\t\tconst unsigned char addr[static ETH_ALEN],\ndrivers/net/dsa/realtek/rtl8365mb_l2.h-22-\t\t\tu16 efid, u16 vid);\ndrivers/net/dsa/realtek/rtl8365mb_l2.h:23:int rtl8365mb_l2_flush(struct realtek_priv *priv, int port, u16 vid);\ndrivers/net/dsa/realtek/rtl8365mb_l2.h-24-\ndrivers/net/dsa/realtek/rtl8365mb_l2.h:25:int rtl8365mb_l2_add_mc(struct realtek_priv *priv, int port,\ndrivers/net/dsa/realtek/rtl8365mb_l2.h-26-\t\t\tconst unsigned char mac_addr[static ETH_ALEN],\ndrivers/net/dsa/realtek/rtl8365mb_l2.h-27-\t\t\tu16 vid);\ndrivers/net/dsa/realtek/rtl8365mb_l2.h:28:int rtl8365mb_l2_del_mc(struct realtek_priv *priv, int port,\ndrivers/net/dsa/realtek/rtl8365mb_l2.h-29-\t\t\tconst unsigned char mac_addr[static ETH_ALEN],\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-64- * require the rtl8367d vendor driver. With all this uncertainty, the driver has\ndrivers/net/dsa/realtek/rtl8365mb_main.c:65: * been modestly named rtl8365mb. Future implementors may wish to rename things\ndrivers/net/dsa/realtek/rtl8365mb_main.c-66- * accordingly.\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-109-#include \"rtl83xx.h\"\ndrivers/net/dsa/realtek/rtl8365mb_main.c:110:#include \"rtl8365mb_l2.h\"\ndrivers/net/dsa/realtek/rtl8365mb_main.c:111:#include \"rtl8365mb_vlan.h\"\ndrivers/net/dsa/realtek/rtl8365mb_main.c-112-\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-259- * 3-bit MSB field (CTRL1). The chip resets them to 0x1FFFF; see\ndrivers/net/dsa/realtek/rtl8365mb_main.c:260: * rtl8365mb_sds_raise_rate_limits().\ndrivers/net/dsa/realtek/rtl8365mb_main.c-261- */\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-427-#define   RTL8365MB_PORT_MISC_CFG_MAC_LOOPBACK_MASK\t\t0x0040\ndrivers/net/dsa/realtek/rtl8365mb_main.c:428:/* See \u0026rtl8365mb_vlan_egress_mode */\ndrivers/net/dsa/realtek/rtl8365mb_main.c-429-#define   RTL8365MB_PORT_MISC_CFG_VLAN_EGRESS_MODE_MASK\t\t0x0030\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-432-/**\ndrivers/net/dsa/realtek/rtl8365mb_main.c:433: * enum rtl8365mb_vlan_egress_mode - port VLAN egress mode\ndrivers/net/dsa/realtek/rtl8365mb_main.c-434- * @RTL8365MB_VLAN_EGRESS_MODE_ORIGINAL: follow untag mask in VLAN4k table entry\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-442- */\ndrivers/net/dsa/realtek/rtl8365mb_main.c:443:enum rtl8365mb_vlan_egress_mode {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-444-\tRTL8365MB_VLAN_EGRESS_MODE_ORIGINAL = 0,\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-486-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:487:enum rtl8365mb_mib_counter_index {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-488-\tRTL8365MB_MIB_ifInOctets,\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-548-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:549:struct rtl8365mb_mib_counter {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-550-\tu32 offset;\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-557-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:558:static struct rtl8365mb_mib_counter rtl8365mb_mib_counters[] = {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-559-\tRTL8365MB_MAKE_MIB_COUNTER(0, 4, ifInOctets),\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-618-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:619:static_assert(ARRAY_SIZE(rtl8365mb_mib_counters) == RTL8365MB_MIB_END);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-620-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:621:struct rtl8365mb_jam_tbl_entry {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-622-\tu16 reg;\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-626-/* Lifted from the vendor driver sources */\ndrivers/net/dsa/realtek/rtl8365mb_main.c:627:static const struct rtl8365mb_jam_tbl_entry rtl8365mb_init_jam_8365mb_vc[] = {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-628-\t{ 0x13EB, 0x15BB }, { 0x1303, 0x06D6 }, { 0x1304, 0x0700 },\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-635-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:636:static const struct rtl8365mb_jam_tbl_entry rtl8365mb_init_jam_common[] = {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-637-\t{ 0x1200, 0x7FCB }, { 0x0884, 0x0003 }, { 0x06EB, 0x0001 },\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-646- * option, which is what RTL8367S parts seen so far report. See\ndrivers/net/dsa/realtek/rtl8365mb_main.c:647: * rtl8365mb_sds_probe_option().\ndrivers/net/dsa/realtek/rtl8365mb_main.c-648- */\ndrivers/net/dsa/realtek/rtl8365mb_main.c:649:static const struct rtl8365mb_jam_tbl_entry rtl8365mb_sds_jam_sgmii[] = {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-650-\t{ 0x0480, 0x04D7 }, { 0x0481, 0xF994 }, { 0x0482, 0x2420 },\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-658- * option, which is what RTL8367S parts seen so far report. See\ndrivers/net/dsa/realtek/rtl8365mb_main.c:659: * rtl8365mb_sds_probe_option().\ndrivers/net/dsa/realtek/rtl8365mb_main.c-660- */\ndrivers/net/dsa/realtek/rtl8365mb_main.c:661:static const struct rtl8365mb_jam_tbl_entry rtl8365mb_sds_jam_hsgmii[] = {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-662-\t{ 0x0500, 0x82F0 }, { 0x0501, 0xF195 }, { 0x0502, 0x31A2 },\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-666-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:667:enum rtl8365mb_phy_interface_mode {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-668-\tRTL8365MB_PHY_INTERFACE_MODE_INVAL = 0,\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-678-/**\ndrivers/net/dsa/realtek/rtl8365mb_main.c:679: * struct rtl8365mb_extint - external interface info\ndrivers/net/dsa/realtek/rtl8365mb_main.c-680- * @port: the port with an external interface\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-684- * Represents a mapping: port -\u003e { id, supported_interfaces }. To be embedded\ndrivers/net/dsa/realtek/rtl8365mb_main.c:685: * in \u0026struct rtl8365mb_chip_info for every port with an external interface.\ndrivers/net/dsa/realtek/rtl8365mb_main.c-686- */\ndrivers/net/dsa/realtek/rtl8365mb_main.c:687:struct rtl8365mb_extint {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-688-\tint port;\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-693-/**\ndrivers/net/dsa/realtek/rtl8365mb_main.c:694: * struct rtl8365mb_chip_info - static chip-specific info\ndrivers/net/dsa/realtek/rtl8365mb_main.c-695- * @name: human-readable chip name\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-703- * by this driver. When adding support for another chip in the family, a new\ndrivers/net/dsa/realtek/rtl8365mb_main.c:704: * chip info should be added to the rtl8365mb_chip_infos array.\ndrivers/net/dsa/realtek/rtl8365mb_main.c-705- */\ndrivers/net/dsa/realtek/rtl8365mb_main.c:706:struct rtl8365mb_chip_info {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-707-\tconst char *name;\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-709-\tu32 chip_ver;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:710:\tconst struct rtl8365mb_extint extints[RTL8365MB_MAX_NUM_EXTINTS];\ndrivers/net/dsa/realtek/rtl8365mb_main.c:711:\tconst struct rtl8365mb_jam_tbl_entry *jam_table;\ndrivers/net/dsa/realtek/rtl8365mb_main.c-712-\tsize_t jam_size;\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-716-#define PHY_INTF(_mode) (RTL8365MB_PHY_INTERFACE_MODE_ ## _mode)\ndrivers/net/dsa/realtek/rtl8365mb_main.c:717:static const struct rtl8365mb_chip_info rtl8365mb_chip_infos[] = {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-718-\t{\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-725-\t\t},\ndrivers/net/dsa/realtek/rtl8365mb_main.c:726:\t\t.jam_table = rtl8365mb_init_jam_8365mb_vc,\ndrivers/net/dsa/realtek/rtl8365mb_main.c:727:\t\t.jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),\ndrivers/net/dsa/realtek/rtl8365mb_main.c-728-\t},\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-737-\t\t},\ndrivers/net/dsa/realtek/rtl8365mb_main.c:738:\t\t.jam_table = rtl8365mb_init_jam_8365mb_vc,\ndrivers/net/dsa/realtek/rtl8365mb_main.c:739:\t\t.jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),\ndrivers/net/dsa/realtek/rtl8365mb_main.c-740-\t},\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-751-\t\t},\ndrivers/net/dsa/realtek/rtl8365mb_main.c:752:\t\t.jam_table = rtl8365mb_init_jam_8365mb_vc,\ndrivers/net/dsa/realtek/rtl8365mb_main.c:753:\t\t.jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),\ndrivers/net/dsa/realtek/rtl8365mb_main.c-754-\t},\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-764-\t\t},\ndrivers/net/dsa/realtek/rtl8365mb_main.c:765:\t\t.jam_table = rtl8365mb_init_jam_8365mb_vc,\ndrivers/net/dsa/realtek/rtl8365mb_main.c:766:\t\t.jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),\ndrivers/net/dsa/realtek/rtl8365mb_main.c-767-\t},\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-769-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:770:enum rtl8365mb_stp_state {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-771-\tRTL8365MB_STP_STATE_DISABLED = 0,\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-776-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:777:enum rtl8365mb_cpu_insert {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-778-\tRTL8365MB_CPU_INSERT_TO_ALL = 0,\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-782-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:783:enum rtl8365mb_cpu_position {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-784-\tRTL8365MB_CPU_POS_AFTER_SA = 0,\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-787-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:788:enum rtl8365mb_cpu_format {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-789-\tRTL8365MB_CPU_FORMAT_8BYTES = 0,\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-792-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:793:enum rtl8365mb_cpu_rxlen {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-794-\tRTL8365MB_CPU_RXLEN_72BYTES = 0,\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-798-/**\ndrivers/net/dsa/realtek/rtl8365mb_main.c:799: * struct rtl8365mb_cpu - CPU port configuration\ndrivers/net/dsa/realtek/rtl8365mb_main.c-800- * @enable: enable/disable hardware insertion of CPU tag in switch-\u003eCPU frames\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-810- */\ndrivers/net/dsa/realtek/rtl8365mb_main.c:811:struct rtl8365mb_cpu {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-812-\tbool enable;\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-814-\tu32 trap_port;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:815:\tenum rtl8365mb_cpu_insert insert;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:816:\tenum rtl8365mb_cpu_position position;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:817:\tenum rtl8365mb_cpu_rxlen rx_length;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:818:\tenum rtl8365mb_cpu_format format;\ndrivers/net/dsa/realtek/rtl8365mb_main.c-819-};\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-821-/**\ndrivers/net/dsa/realtek/rtl8365mb_main.c:822: * struct rtl8365mb_port - private per-port data\ndrivers/net/dsa/realtek/rtl8365mb_main.c-823- * @priv: pointer to parent realtek_priv data\ndrivers/net/dsa/realtek/rtl8365mb_main.c-824- * @index: DSA port index, same as dsa_port::index\ndrivers/net/dsa/realtek/rtl8365mb_main.c:825: * @stats: link statistics populated by rtl8365mb_stats_poll, ready for atomic\ndrivers/net/dsa/realtek/rtl8365mb_main.c:826: *         access via rtl8365mb_get_stats64\ndrivers/net/dsa/realtek/rtl8365mb_main.c-827- * @stats_lock: protect the stats structure during read/update\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-829- */\ndrivers/net/dsa/realtek/rtl8365mb_main.c:830:struct rtl8365mb_port {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-831-\tstruct realtek_priv *priv;\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-838-/**\ndrivers/net/dsa/realtek/rtl8365mb_main.c:839: * struct rtl8365mb - driver private data\ndrivers/net/dsa/realtek/rtl8365mb_main.c-840- * @priv: pointer to parent realtek_priv data\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-851- */\ndrivers/net/dsa/realtek/rtl8365mb_main.c:852:struct rtl8365mb {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-853-\tstruct realtek_priv *priv;\ndrivers/net/dsa/realtek/rtl8365mb_main.c-854-\tint irq;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:855:\tconst struct rtl8365mb_chip_info *chip_info;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:856:\tstruct rtl8365mb_cpu cpu;\ndrivers/net/dsa/realtek/rtl8365mb_main.c-857-\tstruct mutex mib_lock;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:858:\tstruct rtl8365mb_port ports[RTL8365MB_MAX_NUM_PORTS];\ndrivers/net/dsa/realtek/rtl8365mb_main.c-859-\tstruct phylink_pcs pcs;\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-862-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:863:#define pcs_to_rtl8365mb(_pcs) container_of((_pcs), struct rtl8365mb, pcs)\ndrivers/net/dsa/realtek/rtl8365mb_main.c-864-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:865:static int rtl8365mb_phy_poll_busy(struct realtek_priv *priv)\ndrivers/net/dsa/realtek/rtl8365mb_main.c-866-{\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-873-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:874:static int rtl8365mb_phy_ocp_prepare(struct realtek_priv *priv, int phy,\ndrivers/net/dsa/realtek/rtl8365mb_main.c-875-\t\t\t\t     u32 ocp_addr)\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-903-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:904:static int rtl8365mb_phy_ocp_read(struct realtek_priv *priv, int phy,\ndrivers/net/dsa/realtek/rtl8365mb_main.c-905-\t\t\t\t  u32 ocp_addr, u16 *data)\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-911-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:912:\tret = rtl8365mb_phy_poll_busy(priv);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-913-\tif (ret)\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-915-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:916:\tret = rtl8365mb_phy_ocp_prepare(priv, phy, ocp_addr);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-917-\tif (ret)\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-929-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:930:\tret = rtl8365mb_phy_poll_busy(priv);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-931-\tif (ret)\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-947-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:948:static int rtl8365mb_phy_ocp_write(struct realtek_priv *priv, int phy,\ndrivers/net/dsa/realtek/rtl8365mb_main.c-949-\t\t\t\t   u32 ocp_addr, u16 data)\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-955-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:956:\tret = rtl8365mb_phy_poll_busy(priv);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-957-\tif (ret)\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-959-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:960:\tret = rtl8365mb_phy_ocp_prepare(priv, phy, ocp_addr);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-961-\tif (ret)\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-979-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:980:\tret = rtl8365mb_phy_poll_busy(priv);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-981-\tif (ret)\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-989-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:990:static int rtl8365mb_phy_read(struct realtek_priv *priv, int phy, int regnum)\ndrivers/net/dsa/realtek/rtl8365mb_main.c-991-{\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1003-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1004:\tret = rtl8365mb_phy_ocp_read(priv, phy, ocp_addr, \u0026val);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1005-\tif (ret) {\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1017-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1018:static int rtl8365mb_phy_write(struct realtek_priv *priv, int phy, int regnum,\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1019-\t\t\t       u16 val)\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1031-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1032:\tret = rtl8365mb_phy_ocp_write(priv, phy, ocp_addr, val);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1033-\tif (ret) {\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1045-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1046:static const struct rtl8365mb_extint *\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1047:rtl8365mb_get_port_extint(struct realtek_priv *priv, int port)\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1048-{\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1049:\tstruct rtl8365mb *mb = priv-\u003echip_data;\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1050-\tint i;\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1052-\tfor (i = 0; i \u003c RTL8365MB_MAX_NUM_EXTINTS; i++) {\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1053:\t\tconst struct rtl8365mb_extint *extint =\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1054-\t\t\t\u0026mb-\u003echip_info-\u003eextints[i];\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c=1066=static enum dsa_tag_protocol\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1067:rtl8365mb_get_tag_protocol(struct dsa_switch *ds, int port,\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1068-\t\t\t   enum dsa_tag_protocol mp)\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1070-\tstruct realtek_priv *priv = ds-\u003epriv;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1071:\tstruct rtl8365mb_cpu *cpu;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1072:\tstruct rtl8365mb *mb;\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1073-\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1082-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1083:static int rtl8365mb_ext_config_rgmii(struct realtek_priv *priv, int port,\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1084-\t\t\t\t      phy_interface_t interface)\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1085-{\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1086:\tconst struct rtl8365mb_extint *extint =\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1087:\t\trtl8365mb_get_port_extint(priv, port);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1088-\tstruct dsa_switch *ds = \u0026priv-\u003eds;\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1115-\t * forcing the external interface into a particular mode, which is done\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1116:\t * in the rtl8365mb_phylink_mac_link_{up,down} functions.\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1117-\t *\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1164-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1165:static int rtl8365mb_sds_write(struct realtek_priv *priv, u16 addr, u16 data)\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1166-{\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1185-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1186:static int rtl8365mb_sds_read(struct realtek_priv *priv, u16 addr, u16 *data)\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1187-{\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1227- */\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1228:static int rtl8365mb_sds_probe_option(struct realtek_priv *priv)\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1229-{\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1230:\tstruct rtl8365mb *mb = priv-\u003echip_data;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1231:\tconst struct rtl8365mb_extint *extint;\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1232-\tu32 option;\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1273- * their maximum in its switch init, unconditionally for the whole chip\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1274: * family. The chip reset in rtl8365mb_setup() puts them back to their reset\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1275- * default of 0x1FFFF, a ~1.048 Gbps limit which caps the aggregate\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1282- */\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1283:static int rtl8365mb_sds_raise_rate_limits(struct realtek_priv *priv)\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1284-{\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1308-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1309:static int rtl8365mb_pcs_config(struct phylink_pcs *pcs, unsigned int neg_mode,\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1310-\t\t\t\tphy_interface_t interface,\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1313-{\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1314:\tconst struct rtl8365mb_jam_tbl_entry *sds_jam;\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1315-\tconst int id = RTL8365MB_SDS_EXT_INTERFACE_ID;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1316:\tstruct rtl8365mb *mb = pcs_to_rtl8365mb(pcs);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1317-\tstruct realtek_priv *priv;\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1326-\tif (interface == PHY_INTERFACE_MODE_2500BASEX) {\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1327:\t\tsds_jam = rtl8365mb_sds_jam_hsgmii;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1328:\t\tsds_jam_size = ARRAY_SIZE(rtl8365mb_sds_jam_hsgmii);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1329-\t\tmode = RTL8365MB_EXT_PORT_MODE_HSGMII;\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1330-\t} else {\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1331:\t\tsds_jam = rtl8365mb_sds_jam_sgmii;\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1332:\t\tsds_jam_size = ARRAY_SIZE(rtl8365mb_sds_jam_sgmii);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1333-\t\tmode = RTL8365MB_EXT_PORT_MODE_SGMII;\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1363-\tfor (i = 0; i \u003c sds_jam_size; i++) {\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1364:\t\tret = rtl8365mb_sds_write(priv, sds_jam[i].reg,\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1365-\t\t\t\t\t  sds_jam[i].val);\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1390-\t */\ndrivers/net/dsa/realtek/rtl8365mb_main.c:1391:\tret = rtl8365mb_sds_write(priv, RTL8365MB_SDS_REG_RESET,\ndrivers/net/dsa/realtek/rtl8365mb_main.c-1392-\t\t\t\t  RTL8365MB_SDS_RESET_DEASSERT);\n--\n\n"
}

gemini-3.7-flash

null

null

							input: 22315
							output: 37
							thoughts: 43
						

Okay, let's dive into this `rtl8365mb_main.c` file, specifically focusing on the code surrounding the `rtl8365mb_reset_chip` and `rtl8365mb_probe` functions. I need to get a better understanding of how the chip initialization and reset sequences are handled in this driver. I'm assuming, given the naming, that `rtl8365mb_probe` is responsible for detecting and initializing the hardware, which would likely mean allocating resources, configuring the I/O, and probably calling some kind of low-level hardware initialization routine. And that routine would almost certainly be `rtl8365mb_reset_chip`. I'll be looking for things like:

*   How is the chip actually detected? Is it I2C, SPI, or some other interface?
*   What checks are performed during probing to ensure the chip is a valid RTL8365MB? Vendor ID, Device ID, etc.
*   Are there any critical register accesses that determine whether the chip is accessible?
*   What resources are being requested/allocated during probe, like memory regions, IRQs, etc?
*   How does the reset function work? Is it a hard reset? Software reset? What register manipulations are involved?
*   What error handling is in place? Are there retries? Timeout mechanisms?
*   I want to see the sequence of operations. Understanding the exact order will be crucial to understand the chip's power-up and initialization process.

I need to see the dependencies. I suspect the `reset_chip` function is a core function, meaning it's likely a series of direct register reads and writes. I'm also interested in how error codes are handled between the two routines. I'm expecting some pretty low-level stuff here, likely bit manipulation and direct register addresses, hopefully, it’s not too obfuscated. I want to see if this code follows the expected patterns or if there are any unusual approaches. This is where I can start building my hypothesis on how the overall system works.

{
  "Expression": "rtl8365mb_variant",
  "PathPrefix": "drivers/net/dsa/realtek"
}

{
  "Output": "drivers/net/dsa/realtek/realtek.h=193=extern const struct realtek_variant rtl8366rb_variant;\ndrivers/net/dsa/realtek/realtek.h:194:extern const struct realtek_variant rtl8365mb_variant;\ndrivers/net/dsa/realtek/realtek.h-195-\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c=3350=static const char *const rtl8365mb_supplies[] = {\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-3353-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:3354:const struct realtek_variant rtl8365mb_variant = {\ndrivers/net/dsa/realtek/rtl8365mb_main.c-3355-\t.ds_ops = \u0026rtl8365mb_switch_ops,\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c=3366=static const struct of_device_id rtl8365mb_of_match[] = {\ndrivers/net/dsa/realtek/rtl8365mb_main.c:3367:\t{ .compatible = \"realtek,rtl8365mb\", .data = \u0026rtl8365mb_variant, },\ndrivers/net/dsa/realtek/rtl8365mb_main.c-3368-\t{ /* sentinel */ }\n"
}

gemini-3.7-flash

null

null

							input: 23246
							output: 49
							thoughts: 70
						

**Investigating the rtl8365mb Code Usage**

Okay, so I need to understand the scope of `rtl8365mb_variant` and `rtl8365mb_of_match`. I'm going to start by tracing their usage within the driver. My instinct is to check the `rtl8365mb_main.c` file and also look for any cross-references in files related to the SMI or MDIO interfaces like `realtek-smi.c` or `realtek-mdio.c`. This is my usual process when I am understanding the function of specific variables in these drivers. By looking at where these are declared and where they are used, I can get a good feel for their purpose within the Realtek switch driver ecosystem. Time to get to it!

{
  "File": "drivers/net/dsa/realtek/rtl8365mb_main.c",
  "FirstLine": 3350,
  "LineCount": 40
}

{
  "Contents": "3350:\tstatic const char *const rtl8365mb_supplies[] = {\n3351:\t\t\"avddh\", \"avddl\", \"dvddio\", \"dvddio1\", \"dvddl\", \"pllvddl\",\n3352:\t};\n3353:\t\n3354:\tconst struct realtek_variant rtl8365mb_variant = {\n3355:\t\t.ds_ops = \u0026rtl8365mb_switch_ops,\n3356:\t\t.ops = \u0026rtl8365mb_ops,\n3357:\t\t.phylink_mac_ops = \u0026rtl8365mb_phylink_mac_ops,\n3358:\t\t.clk_delay = 10,\n3359:\t\t.cmd_read = 0xb9,\n3360:\t\t.cmd_write = 0xb8,\n3361:\t\t.chip_data_sz = sizeof(struct rtl8365mb),\n3362:\t\t.supplies = rtl8365mb_supplies,\n3363:\t\t.num_supplies = ARRAY_SIZE(rtl8365mb_supplies),\n3364:\t};\n3365:\t\n3366:\tstatic const struct of_device_id rtl8365mb_of_match[] = {\n3367:\t\t{ .compatible = \"realtek,rtl8365mb\", .data = \u0026rtl8365mb_variant, },\n3368:\t\t{ /* sentinel */ }\n3369:\t};\n3370:\tMODULE_DEVICE_TABLE(of, rtl8365mb_of_match);\n3371:\t\n3372:\tstatic struct platform_driver rtl8365mb_smi_driver = {\n3373:\t\t.driver = {\n3374:\t\t\t.name = \"rtl8365mb-smi\",\n3375:\t\t\t.of_match_table = rtl8365mb_of_match,\n3376:\t\t},\n3377:\t\t.probe  = realtek_smi_probe,\n3378:\t\t.remove = realtek_smi_remove,\n3379:\t\t.shutdown = realtek_smi_shutdown,\n3380:\t};\n3381:\t\n3382:\tstatic struct mdio_driver rtl8365mb_mdio_driver = {\n3383:\t\t.mdiodrv.driver = {\n3384:\t\t\t.name = \"rtl8365mb-mdio\",\n3385:\t\t\t.of_match_table = rtl8365mb_of_match,\n3386:\t\t},\n3387:\t\t.probe  = realtek_mdio_probe,\n3388:\t\t.remove = realtek_mdio_remove,\n3389:\t\t.shutdown = realtek_mdio_shutdown,\n"
}

gemini-3.7-flash

null

null

							input: 24290
							output: 39
							thoughts: 118
						

**Initial Driver Exploration**

Okay, so I'm looking at this code and immediately see something interesting: we've got both an `rtl8365mb_smi_driver` and an `rtl8365mb_mdio_driver`. Both are using OF (Device Tree) matching, which is good – cleaner and more flexible. The matching strings for both are "realtek,rtl8365mb", which suggests these drivers are probably handling the same hardware, just through different interfaces. The SMI driver likely handles the Realtek Specific Management Interface (SMI), and the MDIO driver would deal with the MDIO interface of the chip.

Now, the real question is how they hook up and initialize. I need to understand the reset sequence, how the chip gets configured, and where this `rtl8365mb_reset_chip()` function comes into play. Time to track down all calls to `rtl8365mb_reset_chip` to see when and how it's used. That will give me a better understanding of the overall driver operation.

{
  "Expression": "rtl8365mb_reset_chip",
  "PathPrefix": "drivers/net/dsa/realtek"
}

{
  "Output": "drivers/net/dsa/realtek/rtl8365mb_main.c=2954=static int rtl8365mb_switch_init(struct realtek_priv *priv)\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-2983-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:2984:static int rtl8365mb_reset_chip(struct realtek_priv *priv)\ndrivers/net/dsa/realtek/rtl8365mb_main.c-2985-{\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c=3010=static int rtl8365mb_setup(struct dsa_switch *ds)\n--\ndrivers/net/dsa/realtek/rtl8365mb_main.c-3030-\ndrivers/net/dsa/realtek/rtl8365mb_main.c:3031:\tret = rtl8365mb_reset_chip(priv);\ndrivers/net/dsa/realtek/rtl8365mb_main.c-3032-\tif (ret) {\n"
}

gemini-3.7-flash

null

null

							input: 24994
							output: 43
							thoughts: 646
						

**My Assessment of the RTL8365MB Driver's Fuzzing Potential**

Okay, let's break this down. The `rtl8365mb_setup()` function seems to be the entry point for setting up the Realtek RTL8365MB switch, which is a DSA (Distributed Switch Architecture) switch. DSA switches, in general, connect to the MDIO bus or use SMI (Serial Management Interface, which can be platform-specific or GPIO-bitbanged). My immediate question is whether this specific Realtek chip is even *reachable* in a typical virtualized environment like QEMU or Google Compute Engine, especially on an amd64 architecture, which is what I'm targeting.

Let's carefully consider the reasons a target might be unsuitable for fuzzing, according to the instructions. Section 2 highlights the "WHEN TO RETURN WorthFuzzing=false" scenarios.  It lists:

1.  **Structurally unreachable hardware:** Think vendor-specific PCIe switches, SmartNICs, or GPU drivers. Things that require a physical ASIC/PCIe card, not something emulated in standard QEMU.
2.  **Unreachable execution paths:**  This includes driver teardown callbacks like `.remove`, `.shutdown`, and things like `pci_unregister_driver` that only get executed during physical PCI hot-unplugging or driver unbinding via sysfs. Also code paths that are architecture-specific.

So, the key is whether the DSA driver *or* the RTL8365MB, specifically, can even be instantiated or probed in a QEMU/syzkaller environment on amd64.  I see a `rtl8365mb_of_match` with a `.compatible = "realtek,rtl8365mb"`. That means it's likely probed based on the Device Tree. MDIO drivers usually rely on `mdio_driver_register` or platform driver probe.

The real question is: Does syzkaller, or can syzkaller, create or emulate Realtek SMI or MDIO devices?  I'm guessing the answer is no. Based on my experience, DSA drivers for physical switch chips, including RTL8365MB, B53, MV88E6xxx, SJA1105, etc., need *physical* switch IC hardware or platform definitions within the DeviceTree, which are connected to *real* MDIO/SMI buses.

Wait a second, is there *any* way to emulate a DSA switch? Ah! `dsa_loop` in `drivers/net/dsa/dsa_loop.c` - that's a *mock* DSA switch driver for testing.  However, all the *other* DSA drivers (Realtek, SJA1105, Microchip, B53, etc.) are *hardware* switch drivers, built for those specific physical Ethernet switch ICs. The RTL8365MB, specifically, is a physical Ethernet switch chip, likely something like the RTL8365MB-VC or RTL8367S.

Okay, let me check the probe mechanism in `realtek-smi.c` and `realtek-mdio.c` to be sure. My initial gut feeling is this is probably a dead end for fuzzing in a standard environment, but I need to confirm the probe logic.

{
  "File": "drivers/net/dsa/realtek/realtek-smi.c",
  "FirstLine": 1,
  "LineCount": 80
}

{
  "Contents": "   1:\t// SPDX-License-Identifier: GPL-2.0+\n   2:\t/* Realtek Simple Management Interface (SMI) driver\n   3:\t * It can be discussed how \"simple\" this interface is.\n   4:\t *\n   5:\t * The SMI protocol piggy-backs the MDIO MDC and MDIO signals levels\n   6:\t * but the protocol is not MDIO at all. Instead it is a Realtek\n   7:\t * pecularity that need to bit-bang the lines in a special way to\n   8:\t * communicate with the switch.\n   9:\t *\n  10:\t * ASICs we intend to support with this driver:\n  11:\t *\n  12:\t * RTL8366   - The original version, apparently\n  13:\t * RTL8369   - Similar enough to have the same datsheet as RTL8366\n  14:\t * RTL8366RB - Probably reads out \"RTL8366 revision B\", has a quite\n  15:\t *             different register layout from the other two\n  16:\t * RTL8366S  - Is this \"RTL8366 super\"?\n  17:\t * RTL8367   - Has an OpenWRT driver as well\n  18:\t * RTL8368S  - Seems to be an alternative name for RTL8366RB\n  19:\t * RTL8370   - Also uses SMI\n  20:\t *\n  21:\t * Copyright (C) 2017 Linus Walleij \u003clinus.walleij@linaro.org\u003e\n  22:\t * Copyright (C) 2010 Antti Seppälä \u003ca.seppala@gmail.com\u003e\n  23:\t * Copyright (C) 2010 Roman Yeryomin \u003croman@advem.lv\u003e\n  24:\t * Copyright (C) 2011 Colin Leitner \u003ccolin.leitner@googlemail.com\u003e\n  25:\t * Copyright (C) 2009-2010 Gabor Juhos \u003cjuhosg@openwrt.org\u003e\n  26:\t */\n  27:\t\n  28:\t#include \u003clinux/kernel.h\u003e\n  29:\t#include \u003clinux/module.h\u003e\n  30:\t#include \u003clinux/device.h\u003e\n  31:\t#include \u003clinux/spinlock.h\u003e\n  32:\t#include \u003clinux/skbuff.h\u003e\n  33:\t#include \u003clinux/of.h\u003e\n  34:\t#include \u003clinux/delay.h\u003e\n  35:\t#include \u003clinux/gpio/consumer.h\u003e\n  36:\t#include \u003clinux/platform_device.h\u003e\n  37:\t#include \u003clinux/regmap.h\u003e\n  38:\t#include \u003clinux/bitops.h\u003e\n  39:\t#include \u003clinux/if_bridge.h\u003e\n  40:\t\n  41:\t#include \"realtek.h\"\n  42:\t#include \"realtek-smi.h\"\n  43:\t#include \"rtl83xx.h\"\n  44:\t\n  45:\t#define REALTEK_SMI_ACK_RETRY_COUNT\t\t5\n  46:\t\n  47:\tstatic inline void realtek_smi_clk_delay(struct realtek_priv *priv)\n  48:\t{\n  49:\t\tndelay(priv-\u003evariant-\u003eclk_delay);\n  50:\t}\n  51:\t\n  52:\tstatic void realtek_smi_start(struct realtek_priv *priv)\n  53:\t{\n  54:\t\t/* Set GPIO pins to output mode, with initial state:\n  55:\t\t * SCK = 0, SDA = 1\n  56:\t\t */\n  57:\t\tgpiod_direction_output(priv-\u003emdc, 0);\n  58:\t\tgpiod_direction_output(priv-\u003emdio, 1);\n  59:\t\trealtek_smi_clk_delay(priv);\n  60:\t\n  61:\t\t/* CLK 1: 0 -\u003e 1, 1 -\u003e 0 */\n  62:\t\tgpiod_set_value(priv-\u003emdc, 1);\n  63:\t\trealtek_smi_clk_delay(priv);\n  64:\t\tgpiod_set_value(priv-\u003emdc, 0);\n  65:\t\trealtek_smi_clk_delay(priv);\n  66:\t\n  67:\t\t/* CLK 2: */\n  68:\t\tgpiod_set_value(priv-\u003emdc, 1);\n  69:\t\trealtek_smi_clk_delay(priv);\n  70:\t\tgpiod_set_value(priv-\u003emdio, 0);\n  71:\t\trealtek_smi_clk_delay(priv);\n  72:\t\tgpiod_set_value(priv-\u003emdc, 0);\n  73:\t\trealtek_smi_clk_delay(priv);\n  74:\t\tgpiod_set_value(priv-\u003emdio, 1);\n  75:\t}\n  76:\t\n  77:\tstatic void realtek_smi_stop(struct realtek_priv *priv)\n  78:\t{\n  79:\t\trealtek_smi_clk_delay(priv);\n  80:\t\tgpiod_set_value(priv-\u003emdio, 0);\n"
}

gemini-3.7-flash

null

null

							input: 27783
							output: 141
							thoughts: 591
						

**My Assessment: The RTL8365MB Driver is Not Fuzzable in Standard Environments**

Okay, here's my thought process. I need to determine if this Realtek switch driver, `rtl8365mb_main.c`, is a candidate for fuzzing within the constraints of our standard fuzzing setup.

First, I see that the driver communicates with a physical Realtek switch ASIC. It uses either the proprietary SMI protocol (bit-banged GPIO lines, MDC/MDIO) or the standard MDIO bus. Both communication methods rely on OF (Device Tree) bindings, which is typical for embedded systems like ARM/MIPS routers where these switches are commonly used. That alone is a red flag, as I know our fuzzing heavily relies on standard virtualized environments.

I know that amd64 systems, and standard QEMU/GCE virtual machines, don't have a Device Tree binding or a physical Realtek switch ASIC to talk to. Even *if* I could force `CONFIG_OF` to be compiled on amd64, there isn't a virtual device or a mock driver to instantiate or emulate this switch. It's essentially a dead end.

Now, let's confirm this using the triage guidelines. I need to make sure I am following the rules here.

I go back to the reachability guidelines. The primary gate is reachability. The guidelines explicitly state that fuzzing is only appropriate for code that can *execute* in standard virtualized environments. Code that's structurally unreachable gets a hard pass. Furthermore, the guidelines list vendor-specific hardware drivers that require physical ASICs or PCIe cards not emulated in standard QEMU as examples of unreachable code. Sounds familiar...

The RTL8365MB switch driver *absolutely* fits this description. It's for a physical Ethernet switch ASIC (Realtek RTL8365MB/RTL8367S), connected via SMI or MDIO, as described in the Device Tree, and none of this exists in a standard QEMU or GCE environment. It's fundamentally unreachable during fuzzing.

Therefore, `WorthFuzzing` is unequivocally `false`.

Here's a clear structure for the response:

1.  **WorthFuzzing:** `false`
2.  **FocusSymbols:** `[]` (Nothing of immediate interest)
3.  **EnableConfigs:** `[]` (No specific configs needed)
4.  **Reasoning:** The patch touches `rtl8365mb_reset_chip()` within `drivers/net/dsa/realtek/rtl8365mb_main.c`. This function is part of a driver for Realtek Ethernet switch ASICs (RTL8365MB/RTL8367S) that are connected via SMI or MDIO bus. This setup relies on Device Tree-based embedded systems and physical hardware that's not emulated in standard QEMU/GCE environments on amd64. It is structurally unreachable during fuzzing due to the hardware requirement.

{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "The patch modifies chip reset logic and timing in rtl8365mb_reset_chip() within the Realtek RTL8365MB DSA switch driver (drivers/net/dsa/realtek/rtl8365mb_main.c). This driver targets physical Realtek switch ASICs attached via SMI or MDIO buses defined via Device Tree (OF), which are not present or emulated in standard virtualized environments (QEMU/GCE) on amd64. The modified code is structurally unreachable.",
  "WorthFuzzing": false
}

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch modifies chip reset logic and timing in rtl8365mb_reset_chip() within the Realtek RTL8365MB DSA switch driver (drivers/net/dsa/realtek/rtl8365mb_main.c). This driver targets physical Realtek switch ASICs attached via SMI or MDIO buses defined via Device Tree (OF), which are not present or emulated in standard virtualized environments (QEMU/GCE) on amd64. The modified code is structurally unreachable.",
  "WorthFuzzing": false
}

{
  "WorthFuzzing": false
}

null