AI Trajectory

null

{
  "EnableConfigs": [
    "PSE_CONTROLLER",
    "PSE_REGULATOR",
    "REGULATOR",
    "SFP",
    "FWNODE_MDIO"
  ],
  "FocusSymbols": [
    "phy_pse_control_lock",
    "phy_pse_control_unlock",
    "phy_device_register_locked",
    "phy_device_register",
    "phy_device_remove",
    "pse_register_notifier",
    "pse_unregister_notifier",
    "pse_controller_register",
    "pse_controller_unregister",
    "pse_control_matches_pcdev",
    "ethnl_set_pse",
    "pse_prepare_data",
    "phy_pse_attach_one",
    "phy_pse_detach_one",
    "phy_pse_notifier_event"
  ],
  "KMSANReasoning": "The patch series refactors the lifecycle and synchronization of PSE (Power Sourcing Equipment) controllers attached to PHY devices. It introduces a notifier chain (`phy_pse_notifier`) and a mutex (`phy_pse_lock`) to safely attach and detach `phydev-\u003epsec` when PSE controllers are registered or unregistered, preventing race conditions and use-after-free bugs. It also wraps ethtool PSE operations with the new lock.\n\nThese changes primarily address object lifecycle management, locking, and synchronization. Any bugs introduced by these changes would likely manifest as use-after-free, NULL pointer dereferences, or deadlocks, which are effectively caught by standard KASAN and LOCKDEP. The patch does not introduce new data structures sent to user space, nor does it involve complex buffer allocations or modifications to data length calculations that could expose uninitialized memory. Therefore, a dedicated KMSAN fuzzing session is not justified.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch changes how the PSE controller is attached to the PHY device, introducing a new lock (`phy_pse_lock`) and a notifier (`phy_pse_notifier`) to handle PSE controller registration and unregistration. It also modifies the ethtool PSE netlink interface to use the new lock. These changes affect the core PHY library and ethtool, and are reachable via netlink and PHY device registration paths, which can be triggered in virtualized environments.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 668d093b09ff0e42bb4ab399d14e2aa0007ba5cd\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Wed Aug 26 22:10:39 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c\nindex ba70915182654..7bd979b59f496 100644\n--- a/drivers/net/mdio/fwnode_mdio.c\n+++ b/drivers/net/mdio/fwnode_mdio.c\n@@ -11,33 +11,11 @@\n #include \u003clinux/fwnode_mdio.h\u003e\n #include \u003clinux/of.h\u003e\n #include \u003clinux/phy.h\u003e\n-#include \u003clinux/pse-pd/pse.h\u003e\n \n MODULE_AUTHOR(\"Calvin Johnson \u003ccalvin.johnson@oss.nxp.com\u003e\");\n MODULE_LICENSE(\"GPL\");\n MODULE_DESCRIPTION(\"FWNODE MDIO bus (Ethernet PHY) accessors\");\n \n-static struct pse_control *\n-fwnode_find_pse_control(struct fwnode_handle *fwnode,\n-\t\t\tstruct phy_device *phydev)\n-{\n-\tstruct pse_control *psec;\n-\tstruct device_node *np;\n-\n-\tif (!IS_ENABLED(CONFIG_PSE_CONTROLLER))\n-\t\treturn NULL;\n-\n-\tnp = to_of_node(fwnode);\n-\tif (!np)\n-\t\treturn NULL;\n-\n-\tpsec = of_pse_control_get(np, phydev);\n-\tif (PTR_ERR(psec) == -ENOENT)\n-\t\treturn NULL;\n-\n-\treturn psec;\n-}\n-\n static struct mii_timestamper *\n fwnode_find_mii_timestamper(struct fwnode_handle *fwnode)\n {\n@@ -118,7 +96,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,\n \t\t\t\tstruct fwnode_handle *child, u32 addr)\n {\n \tstruct mii_timestamper *mii_ts = NULL;\n-\tstruct pse_control *psec = NULL;\n \tstruct phy_device *phy;\n \tbool is_c45;\n \tu32 phy_id;\n@@ -159,14 +136,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,\n \t\t\tgoto clean_phy;\n \t}\n \n-\tpsec = fwnode_find_pse_control(child, phy);\n-\tif (IS_ERR(psec)) {\n-\t\trc = PTR_ERR(psec);\n-\t\tgoto unregister_phy;\n-\t}\n-\n-\tphy-\u003epsec = psec;\n-\n \t/* phy-\u003emii_ts may already be defined by the PHY driver. A\n \t * mii_timestamper probed via the device tree will still have\n \t * precedence.\n@@ -176,9 +145,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,\n \n \treturn 0;\n \n-unregister_phy:\n-\tif (is_acpi_node(child) || is_of_node(child))\n-\t\tphy_device_remove(phy);\n clean_phy:\n \tphy_device_free(phy);\n clean_mii_ts:\ndiff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c\nindex 0615228459ef4..dca1b45bbbd26 100644\n--- a/drivers/net/phy/phy_device.c\n+++ b/drivers/net/phy/phy_device.c\n@@ -1102,11 +1102,128 @@ struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45)\n }\n EXPORT_SYMBOL(get_phy_device);\n \n+/* Serialises phydev-\u003epsec against the PSE notifier and ethtool, not rtnl. */\n+static DEFINE_MUTEX(phy_pse_lock);\n+\n+/* Best-effort attach of phydev-\u003epsec from a DT `pses = \u003c\u0026...\u003e` phandle.\n+ * Caller must hold phy_pse_lock. A missing phandle (-ENOENT) or a\n+ * not-yet-registered controller (-EPROBE_DEFER) is silent; the notifier\n+ * retries the latter at PSE_REGISTERED time. Any other error means a broken\n+ * binding and is warned about, but left non-fatal so the phy still registers.\n+ */\n+static void phy_try_attach_pse(struct phy_device *phydev)\n+{\n+\tstruct pse_control *psec;\n+\tstruct device_node *np;\n+\n+\tlockdep_assert_held(\u0026phy_pse_lock);\n+\n+\tnp = phydev-\u003emdio.dev.of_node;\n+\tif (!np)\n+\t\treturn;\n+\n+\tif (phydev-\u003epsec)\n+\t\treturn;\n+\n+\tpsec = of_pse_control_get(np, phydev);\n+\tif (IS_ERR(psec)) {\n+\t\tif (PTR_ERR(psec) != -EPROBE_DEFER \u0026\u0026 PTR_ERR(psec) != -ENOENT)\n+\t\t\tphydev_warn(phydev, \"failed to get PSE control: %pe\\n\",\n+\t\t\t\t    psec);\n+\t\treturn;\n+\t}\n+\n+\tphydev-\u003epsec = psec;\n+}\n+\n+static int phy_pse_attach_one(struct device *dev, void *data __maybe_unused)\n+{\n+\tlockdep_assert_held(\u0026phy_pse_lock);\n+\n+\tif (dev-\u003etype != \u0026mdio_bus_phy_type)\n+\t\treturn 0;\n+\n+\tphy_try_attach_pse(to_phy_device(dev));\n+\treturn 0;\n+}\n+\n+static int phy_pse_detach_one(struct device *dev, void *data)\n+{\n+\tstruct pse_controller_dev *pcdev = data;\n+\tstruct phy_device *phydev;\n+\tstruct pse_control *psec;\n+\n+\tlockdep_assert_held(\u0026phy_pse_lock);\n+\n+\tif (dev-\u003etype != \u0026mdio_bus_phy_type)\n+\t\treturn 0;\n+\n+\tphydev = to_phy_device(dev);\n+\tpsec = phydev-\u003epsec;\n+\tif (!psec || !pse_control_matches_pcdev(psec, pcdev))\n+\t\treturn 0;\n+\n+\tphydev-\u003epsec = NULL;\n+\tpse_control_put(psec);\n+\treturn 0;\n+}\n+\n+static int phy_pse_notifier_event(struct notifier_block *nb,\n+\t\t\t\t  unsigned long event, void *data)\n+{\n+\tswitch (event) {\n+\tcase PSE_REGISTERED:\n+\t\tmutex_lock(\u0026phy_pse_lock);\n+\t\tbus_for_each_dev(\u0026mdio_bus_type, NULL, NULL,\n+\t\t\t\t phy_pse_attach_one);\n+\t\tmutex_unlock(\u0026phy_pse_lock);\n+\t\treturn NOTIFY_OK;\n+\tcase PSE_UNREGISTERED:\n+\t\tmutex_lock(\u0026phy_pse_lock);\n+\t\tbus_for_each_dev(\u0026mdio_bus_type, NULL, data,\n+\t\t\t\t phy_pse_detach_one);\n+\t\tmutex_unlock(\u0026phy_pse_lock);\n+\t\treturn NOTIFY_OK;\n+\tdefault:\n+\t\treturn NOTIFY_DONE;\n+\t}\n+}\n+\n+static struct notifier_block phy_pse_notifier __read_mostly = {\n+\t.notifier_call = phy_pse_notifier_event,\n+};\n+\n /**\n- * phy_device_register - Register the phy device on the MDIO bus\n- * @phydev: phy_device structure to be added to the MDIO bus\n+ * phy_pse_control_lock - hold phydev-\u003epsec stable against PSE controller teardown\n+ *\n+ * The PSE_UNREGISTERED notifier detaches phydev-\u003epsec and drops its last\n+ * reference. Callers that dereference phydev-\u003epsec (the ethtool PSE paths) must\n+ * hold this lock across the access so the detach cannot run underneath them.\n  */\n-int phy_device_register(struct phy_device *phydev)\n+void phy_pse_control_lock(void)\n+{\n+\tmutex_lock(\u0026phy_pse_lock);\n+}\n+EXPORT_SYMBOL_GPL(phy_pse_control_lock);\n+\n+/**\n+ * phy_pse_control_unlock - release the lock taken by phy_pse_control_lock()\n+ */\n+void phy_pse_control_unlock(void)\n+{\n+\tmutex_unlock(\u0026phy_pse_lock);\n+}\n+EXPORT_SYMBOL_GPL(phy_pse_control_unlock);\n+\n+/* Core registration: add the phy to the MDIO bus. Does not touch rtnl or\n+ * PSE. phydev-\u003epsec is attached by the callers below, after device_add()\n+ * has made the phy visible on mdio_bus_type, so that a concurrent PSE\n+ * notifier walk and the attach can never leave the phy unattached. Keeping\n+ * device_add() out of rtnl also avoids deadlocking when binding a phy that\n+ * itself provides an SFP cage (phy_probe() -\u003e phy_sfp_probe() -\u003e\n+ * sfp_bus_add_upstream() takes rtnl).\n+ */\n+static int __phy_device_register(struct phy_device *phydev)\n {\n \tint err;\n \n@@ -1135,10 +1252,56 @@ int phy_device_register(struct phy_device *phydev)\n  out:\n \t/* Assert the reset signal */\n \tphy_device_reset(phydev, 1);\n-\n \tmdiobus_unregister_device(\u0026phydev-\u003emdio);\n \treturn err;\n }\n+\n+/**\n+ * phy_device_register_locked - Register the phy device on the MDIO bus\n+ * @phydev: phy_device structure to be added to the MDIO bus\n+ *\n+ * Same as phy_device_register() but caller must already hold rtnl_lock().\n+ *\n+ * Return: 0 on success, negative error code on failure.\n+ */\n+int phy_device_register_locked(struct phy_device *phydev)\n+{\n+\tint err;\n+\n+\tASSERT_RTNL();\n+\n+\terr = __phy_device_register(phydev);\n+\tif (err)\n+\t\treturn err;\n+\n+\tmutex_lock(\u0026phy_pse_lock);\n+\tphy_try_attach_pse(phydev);\n+\tmutex_unlock(\u0026phy_pse_lock);\n+\n+\treturn 0;\n+}\n+EXPORT_SYMBOL(phy_device_register_locked);\n+\n+/**\n+ * phy_device_register - Register the phy device on the MDIO bus\n+ * @phydev: phy_device structure to be added to the MDIO bus\n+ *\n+ * Return: 0 on success, negative error code on failure.\n+ */\n+int phy_device_register(struct phy_device *phydev)\n+{\n+\tint err;\n+\n+\terr = __phy_device_register(phydev);\n+\tif (err)\n+\t\treturn err;\n+\n+\tmutex_lock(\u0026phy_pse_lock);\n+\tphy_try_attach_pse(phydev);\n+\tmutex_unlock(\u0026phy_pse_lock);\n+\n+\treturn 0;\n+}\n EXPORT_SYMBOL(phy_device_register);\n \n /**\n@@ -1152,7 +1315,15 @@ EXPORT_SYMBOL(phy_device_register);\n void phy_device_remove(struct phy_device *phydev)\n {\n \tunregister_mii_timestamper(phydev-\u003emii_ts);\n+\n+\t/* Detach synchronously, before the phy leaves the bus, so the put cannot\n+\t * outlive the PSE controller (an off-bus but still-pinned phy is missed by\n+\t * the PSE_UNREGISTERED walk). phy_pse_lock serialises against that walk.\n+\t */\n+\tmutex_lock(\u0026phy_pse_lock);\n \tpse_control_put(phydev-\u003epsec);\n+\tphydev-\u003epsec = NULL;\n+\tmutex_unlock(\u0026phy_pse_lock);\n \n \tdevice_del(\u0026phydev-\u003emdio.dev);\n \n@@ -3981,8 +4152,14 @@ static int __init phy_init(void)\n \tif (rc)\n \t\tgoto err_c45;\n \n+\trc = pse_register_notifier(\u0026phy_pse_notifier);\n+\tif (rc)\n+\t\tgoto err_genphy;\n+\n \treturn 0;\n \n+err_genphy:\n+\tphy_driver_unregister(\u0026genphy_driver);\n err_c45:\n \tphy_driver_unregister(\u0026genphy_c45_driver);\n err_ethtool_phy_ops:\n@@ -3999,6 +4176,7 @@ static int __init phy_init(void)\n \n static void __exit phy_exit(void)\n {\n+\tpse_unregister_notifier(\u0026phy_pse_notifier);\n \tphy_driver_unregister(\u0026genphy_c45_driver);\n \tphy_driver_unregister(\u0026genphy_driver);\n \trtnl_lock();\ndiff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c\nindex 03bfd8640db96..18868bdd64852 100644\n--- a/drivers/net/phy/sfp.c\n+++ b/drivers/net/phy/sfp.c\n@@ -2083,7 +2083,7 @@ static int sfp_sm_probe_phy(struct sfp *sfp, int addr, bool is_c45)\n \t/* Mark this PHY as being on a SFP module */\n \tphy-\u003eis_on_sfp_module = true;\n \n-\terr = phy_device_register(phy);\n+\terr = phy_device_register_locked(phy);\n \tif (err) {\n \t\tphy_device_free(phy);\n \t\tdev_err(sfp-\u003edev, \"phy_device_register failed: %pe\\n\",\ndiff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c\nindex 69dbdbde9d71a..611540df43bb1 100644\n--- a/drivers/net/pse-pd/pse_core.c\n+++ b/drivers/net/pse-pd/pse_core.c\n@@ -8,6 +8,7 @@\n #include \u003clinux/device.h\u003e\n #include \u003clinux/ethtool.h\u003e\n #include \u003clinux/ethtool_netlink.h\u003e\n+#include \u003clinux/notifier.h\u003e\n #include \u003clinux/of.h\u003e\n #include \u003clinux/phy.h\u003e\n #include \u003clinux/pse-pd/pse.h\u003e\n@@ -23,6 +24,39 @@ static LIST_HEAD(pse_controller_list);\n static DEFINE_XARRAY_ALLOC(pse_pw_d_map);\n static DEFINE_MUTEX(pse_pw_d_mutex);\n \n+static BLOCKING_NOTIFIER_HEAD(pse_controller_notifier);\n+\n+/**\n+ * pse_register_notifier - register a callback for PSE controller events\n+ * @nb: notifier block to register\n+ *\n+ * See enum pse_controller_event for events fired and their subscriber\n+ * contract. Callbacks run in process context; they may sleep, take\n+ * rtnl, and call of_pse_control_get(). The chain fires synchronously,\n+ * so a PSE controller driver's probe/unbind path must not hold any\n+ * such lock when calling pse_controller_register() or\n+ * pse_controller_unregister().\n+ *\n+ * Return: 0 on success, negative error code otherwise.\n+ */\n+int pse_register_notifier(struct notifier_block *nb)\n+{\n+\treturn blocking_notifier_chain_register(\u0026pse_controller_notifier, nb);\n+}\n+EXPORT_SYMBOL_GPL(pse_register_notifier);\n+\n+/**\n+ * pse_unregister_notifier - unregister a previously registered callback\n+ * @nb: notifier block previously passed to pse_register_notifier()\n+ *\n+ * Return: 0 on success, negative error code otherwise.\n+ */\n+int pse_unregister_notifier(struct notifier_block *nb)\n+{\n+\treturn blocking_notifier_chain_unregister(\u0026pse_controller_notifier, nb);\n+}\n+EXPORT_SYMBOL_GPL(pse_unregister_notifier);\n+\n /**\n  * struct pse_control - a PSE control\n  * @pcdev: a pointer to the PSE controller device\n@@ -1104,6 +1138,9 @@ int pse_controller_register(struct pse_controller_dev *pcdev)\n \tlist_add(\u0026pcdev-\u003elist, \u0026pse_controller_list);\n \tmutex_unlock(\u0026pse_list_mutex);\n \n+\tblocking_notifier_call_chain(\u0026pse_controller_notifier,\n+\t\t\t\t     PSE_REGISTERED, pcdev);\n+\n \treturn 0;\n }\n EXPORT_SYMBOL_GPL(pse_controller_register);\n@@ -1114,6 +1151,9 @@ EXPORT_SYMBOL_GPL(pse_controller_register);\n  */\n void pse_controller_unregister(struct pse_controller_dev *pcdev)\n {\n+\tblocking_notifier_call_chain(\u0026pse_controller_notifier,\n+\t\t\t\t     PSE_UNREGISTERED, pcdev);\n+\n \tpse_flush_pw_ds(pcdev);\n \tpse_release_pis(pcdev);\n \tif (pcdev-\u003eirq)\n@@ -1981,3 +2021,17 @@ bool pse_has_c33(struct pse_control *psec)\n \treturn psec-\u003epcdev-\u003etypes \u0026 ETHTOOL_PSE_C33;\n }\n EXPORT_SYMBOL_GPL(pse_has_c33);\n+\n+/**\n+ * pse_control_matches_pcdev - Test whether a pse_control targets a controller\n+ * @psec: pse_control obtained from of_pse_control_get()\n+ * @pcdev: PSE controller to compare against\n+ *\n+ * Return: %true if @psec was obtained from @pcdev, %false otherwise.\n+ */\n+bool pse_control_matches_pcdev(struct pse_control *psec,\n+\t\t\t       struct pse_controller_dev *pcdev)\n+{\n+\treturn psec-\u003epcdev == pcdev;\n+}\n+EXPORT_SYMBOL_GPL(pse_control_matches_pcdev);\ndiff --git a/include/linux/phy.h b/include/linux/phy.h\nindex 199a7aaa341bf..55a0049c6c2b5 100644\n--- a/include/linux/phy.h\n+++ b/include/linux/phy.h\n@@ -2158,8 +2158,12 @@ struct phy_device *fwnode_phy_find_device(struct fwnode_handle *phy_fwnode);\n struct fwnode_handle *fwnode_get_phy_node(const struct fwnode_handle *fwnode);\n struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);\n int phy_device_register(struct phy_device *phy);\n+/* Caller must hold rtnl_lock(); see phy_device_register() for the public form. */\n+int phy_device_register_locked(struct phy_device *phy);\n void phy_device_free(struct phy_device *phydev);\n void phy_device_remove(struct phy_device *phydev);\n+void phy_pse_control_lock(void);\n+void phy_pse_control_unlock(void);\n int phy_get_c45_ids(struct phy_device *phydev);\n int phy_init_hw(struct phy_device *phydev);\n int phy_suspend(struct phy_device *phydev);\ndiff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h\nindex 4e5696cfade7c..d4310ca71a3e0 100644\n--- a/include/linux/pse-pd/pse.h\n+++ b/include/linux/pse-pd/pse.h\n@@ -21,6 +21,7 @@ struct net_device;\n struct phy_device;\n struct pse_controller_dev;\n struct netlink_ext_ack;\n+struct notifier_block;\n \n /* C33 PSE extended state and substate. */\n struct ethtool_c33_pse_ext_state_info {\n@@ -337,6 +338,24 @@ enum pse_budget_eval_strategies {\n \tPSE_BUDGET_EVAL_STRAT_DYNAMIC\t= 1 \u003c\u003c 2,\n };\n \n+/**\n+ * enum pse_controller_event - PSE controller lifecycle events\n+ *\n+ * Event data in callbacks is always a pointer to the struct\n+ * pse_controller_dev firing the event.\n+ *\n+ * @PSE_REGISTERED: controller added to pse_controller_list and\n+ *\tresolvable by of_pse_control_get().\n+ * @PSE_UNREGISTERED: controller about to be removed from\n+ *\tpse_controller_list. Subscribers holding pse_control references\n+ *\ttargeting it must drop them before returning and must not\n+ *\tacquire new references for it.\n+ */\n+enum pse_controller_event {\n+\tPSE_REGISTERED,\n+\tPSE_UNREGISTERED,\n+};\n+\n #if IS_ENABLED(CONFIG_PSE_CONTROLLER)\n int pse_controller_register(struct pse_controller_dev *pcdev);\n void pse_controller_unregister(struct pse_controller_dev *pcdev);\n@@ -366,6 +385,12 @@ int pse_ethtool_set_prio(struct pse_control *psec,\n bool pse_has_podl(struct pse_control *psec);\n bool pse_has_c33(struct pse_control *psec);\n \n+bool pse_control_matches_pcdev(struct pse_control *psec,\n+\t\t\t       struct pse_controller_dev *pcdev);\n+\n+int pse_register_notifier(struct notifier_block *nb);\n+int pse_unregister_notifier(struct notifier_block *nb);\n+\n #else\n \n static inline struct pse_control *of_pse_control_get(struct device_node *node,\n@@ -416,6 +441,22 @@ static inline bool pse_has_c33(struct pse_control *psec)\n \treturn false;\n }\n \n+static inline bool pse_control_matches_pcdev(struct pse_control *psec,\n+\t\t\t\t\t     struct pse_controller_dev *pcdev)\n+{\n+\treturn false;\n+}\n+\n+static inline int pse_register_notifier(struct notifier_block *nb)\n+{\n+\treturn 0;\n+}\n+\n+static inline int pse_unregister_notifier(struct notifier_block *nb)\n+{\n+\treturn 0;\n+}\n+\n #endif\n \n #endif\ndiff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c\nindex 757c9e0cc856f..4edd9a514de14 100644\n--- a/net/ethtool/pse-pd.c\n+++ b/net/ethtool/pse-pd.c\n@@ -71,7 +71,9 @@ static int pse_prepare_data(const struct ethnl_req_info *req_base,\n \tif (ret \u003c 0)\n \t\treturn ret;\n \n+\tphy_pse_control_lock();\n \tret = pse_get_pse_attributes(phydev, info-\u003eextack, data);\n+\tphy_pse_control_unlock();\n \n \tethnl_ops_complete(dev);\n \n@@ -281,9 +283,12 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)\n \n \tphydev = ethnl_req_get_phydev(req_info, tb, ETHTOOL_A_PSE_HEADER,\n \t\t\t\t      info-\u003eextack);\n+\n+\tphy_pse_control_lock();\n+\n \tret = ethnl_set_pse_validate(phydev, info);\n \tif (ret)\n-\t\treturn ret;\n+\t\tgoto out;\n \n \tif (tb[ETHTOOL_A_PSE_PRIO]) {\n \t\tunsigned int prio;\n@@ -291,7 +296,7 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)\n \t\tprio = nla_get_u32(tb[ETHTOOL_A_PSE_PRIO]);\n \t\tret = pse_ethtool_set_prio(phydev-\u003epsec, info-\u003eextack, prio);\n \t\tif (ret)\n-\t\t\treturn ret;\n+\t\t\tgoto out;\n \t}\n \n \tif (tb[ETHTOOL_A_C33_PSE_AVAIL_PW_LIMIT]) {\n@@ -301,7 +306,7 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)\n \t\tret = pse_ethtool_set_pw_limit(phydev-\u003epsec, info-\u003eextack,\n \t\t\t\t\t       pw_limit);\n \t\tif (ret)\n-\t\t\treturn ret;\n+\t\t\tgoto out;\n \t}\n \n \t/* These values are already validated by the ethnl_pse_set_policy */\n@@ -319,11 +324,11 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)\n \t\t */\n \t\tret = pse_ethtool_set_config(phydev-\u003epsec, info-\u003eextack,\n \t\t\t\t\t     \u0026config);\n-\t\tif (ret)\n-\t\t\treturn ret;\n \t}\n \n+out:\n \t/* Return errno or zero - PSE has no notification */\n+\tphy_pse_control_unlock();\n \treturn ret;\n }\n \n"
}

best-expensive

null

{
  "EnableConfigs": [
    "PSE_CONTROLLER",
    "PSE_REGULATOR",
    "REGULATOR",
    "SFP",
    "FWNODE_MDIO"
  ],
  "FocusSymbols": [
    "phy_pse_control_lock",
    "phy_pse_control_unlock",
    "phy_device_register_locked",
    "phy_device_register",
    "phy_device_remove",
    "pse_register_notifier",
    "pse_unregister_notifier",
    "pse_controller_register",
    "pse_controller_unregister",
    "pse_control_matches_pcdev",
    "ethnl_set_pse",
    "pse_prepare_data",
    "phy_pse_attach_one",
    "phy_pse_detach_one",
    "phy_pse_notifier_event"
  ],
  "Reasoning": "The patch changes how the PSE controller is attached to the PHY device, introducing a new lock (`phy_pse_lock`) and a notifier (`phy_pse_notifier`) to handle PSE controller registration and unregistration. It also modifies the ethtool PSE netlink interface to use the new lock. These changes affect the core PHY library and ethtool, and are reachable via netlink and PHY device registration paths, which can be triggered in virtualized environments.",
  "WorthFuzzing": true
}

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 668d093b09ff0e42bb4ab399d14e2aa0007ba5cd
Author: syz-cluster <triage@syzkaller.com>
Date:   Wed Aug 26 22:10:39 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c
index ba70915182654..7bd979b59f496 100644
--- a/drivers/net/mdio/fwnode_mdio.c
+++ b/drivers/net/mdio/fwnode_mdio.c
@@ -11,33 +11,11 @@
 #include <linux/fwnode_mdio.h>
 #include <linux/of.h>
 #include <linux/phy.h>
-#include <linux/pse-pd/pse.h>
 
 MODULE_AUTHOR("Calvin Johnson <calvin.johnson@oss.nxp.com>");
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("FWNODE MDIO bus (Ethernet PHY) accessors");
 
-static struct pse_control *
-fwnode_find_pse_control(struct fwnode_handle *fwnode,
-			struct phy_device *phydev)
-{
-	struct pse_control *psec;
-	struct device_node *np;
-
-	if (!IS_ENABLED(CONFIG_PSE_CONTROLLER))
-		return NULL;
-
-	np = to_of_node(fwnode);
-	if (!np)
-		return NULL;
-
-	psec = of_pse_control_get(np, phydev);
-	if (PTR_ERR(psec) == -ENOENT)
-		return NULL;
-
-	return psec;
-}
-
 static struct mii_timestamper *
 fwnode_find_mii_timestamper(struct fwnode_handle *fwnode)
 {
@@ -118,7 +96,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 				struct fwnode_handle *child, u32 addr)
 {
 	struct mii_timestamper *mii_ts = NULL;
-	struct pse_control *psec = NULL;
 	struct phy_device *phy;
 	bool is_c45;
 	u32 phy_id;
@@ -159,14 +136,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 			goto clean_phy;
 	}
 
-	psec = fwnode_find_pse_control(child, phy);
-	if (IS_ERR(psec)) {
-		rc = PTR_ERR(psec);
-		goto unregister_phy;
-	}
-
-	phy->psec = psec;
-
 	/* phy->mii_ts may already be defined by the PHY driver. A
 	 * mii_timestamper probed via the device tree will still have
 	 * precedence.
@@ -176,9 +145,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 
 	return 0;
 
-unregister_phy:
-	if (is_acpi_node(child) || is_of_node(child))
-		phy_device_remove(phy);
 clean_phy:
 	phy_device_free(phy);
 clean_mii_ts:
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 0615228459ef4..dca1b45bbbd26 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1102,11 +1102,128 @@ struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45)
 }
 EXPORT_SYMBOL(get_phy_device);
 
+/* Serialises phydev->psec against the PSE notifier and ethtool, not rtnl. */
+static DEFINE_MUTEX(phy_pse_lock);
+
+/* Best-effort attach of phydev->psec from a DT `pses = <&...>` phandle.
+ * Caller must hold phy_pse_lock. A missing phandle (-ENOENT) or a
+ * not-yet-registered controller (-EPROBE_DEFER) is silent; the notifier
+ * retries the latter at PSE_REGISTERED time. Any other error means a broken
+ * binding and is warned about, but left non-fatal so the phy still registers.
+ */
+static void phy_try_attach_pse(struct phy_device *phydev)
+{
+	struct pse_control *psec;
+	struct device_node *np;
+
+	lockdep_assert_held(&phy_pse_lock);
+
+	np = phydev->mdio.dev.of_node;
+	if (!np)
+		return;
+
+	if (phydev->psec)
+		return;
+
+	psec = of_pse_control_get(np, phydev);
+	if (IS_ERR(psec)) {
+		if (PTR_ERR(psec) != -EPROBE_DEFER && PTR_ERR(psec) != -ENOENT)
+			phydev_warn(phydev, "failed to get PSE control: %pe\n",
+				    psec);
+		return;
+	}
+
+	phydev->psec = psec;
+}
+
+static int phy_pse_attach_one(struct device *dev, void *data __maybe_unused)
+{
+	lockdep_assert_held(&phy_pse_lock);
+
+	if (dev->type != &mdio_bus_phy_type)
+		return 0;
+
+	phy_try_attach_pse(to_phy_device(dev));
+	return 0;
+}
+
+static int phy_pse_detach_one(struct device *dev, void *data)
+{
+	struct pse_controller_dev *pcdev = data;
+	struct phy_device *phydev;
+	struct pse_control *psec;
+
+	lockdep_assert_held(&phy_pse_lock);
+
+	if (dev->type != &mdio_bus_phy_type)
+		return 0;
+
+	phydev = to_phy_device(dev);
+	psec = phydev->psec;
+	if (!psec || !pse_control_matches_pcdev(psec, pcdev))
+		return 0;
+
+	phydev->psec = NULL;
+	pse_control_put(psec);
+	return 0;
+}
+
+static int phy_pse_notifier_event(struct notifier_block *nb,
+				  unsigned long event, void *data)
+{
+	switch (event) {
+	case PSE_REGISTERED:
+		mutex_lock(&phy_pse_lock);
+		bus_for_each_dev(&mdio_bus_type, NULL, NULL,
+				 phy_pse_attach_one);
+		mutex_unlock(&phy_pse_lock);
+		return NOTIFY_OK;
+	case PSE_UNREGISTERED:
+		mutex_lock(&phy_pse_lock);
+		bus_for_each_dev(&mdio_bus_type, NULL, data,
+				 phy_pse_detach_one);
+		mutex_unlock(&phy_pse_lock);
+		return NOTIFY_OK;
+	default:
+		return NOTIFY_DONE;
+	}
+}
+
+static struct notifier_block phy_pse_notifier __read_mostly = {
+	.notifier_call = phy_pse_notifier_event,
+};
+
 /**
- * phy_device_register - Register the phy device on the MDIO bus
- * @phydev: phy_device structure to be added to the MDIO bus
+ * phy_pse_control_lock - hold phydev->psec stable against PSE controller teardown
+ *
+ * The PSE_UNREGISTERED notifier detaches phydev->psec and drops its last
+ * reference. Callers that dereference phydev->psec (the ethtool PSE paths) must
+ * hold this lock across the access so the detach cannot run underneath them.
  */
-int phy_device_register(struct phy_device *phydev)
+void phy_pse_control_lock(void)
+{
+	mutex_lock(&phy_pse_lock);
+}
+EXPORT_SYMBOL_GPL(phy_pse_control_lock);
+
+/**
+ * phy_pse_control_unlock - release the lock taken by phy_pse_control_lock()
+ */
+void phy_pse_control_unlock(void)
+{
+	mutex_unlock(&phy_pse_lock);
+}
+EXPORT_SYMBOL_GPL(phy_pse_control_unlock);
+
+/* Core registration: add the phy to the MDIO bus. Does not touch rtnl or
+ * PSE. phydev->psec is attached by the callers below, after device_add()
+ * has made the phy visible on mdio_bus_type, so that a concurrent PSE
+ * notifier walk and the attach can never leave the phy unattached. Keeping
+ * device_add() out of rtnl also avoids deadlocking when binding a phy that
+ * itself provides an SFP cage (phy_probe() -> phy_sfp_probe() ->
+ * sfp_bus_add_upstream() takes rtnl).
+ */
+static int __phy_device_register(struct phy_device *phydev)
 {
 	int err;
 
@@ -1135,10 +1252,56 @@ int phy_device_register(struct phy_device *phydev)
  out:
 	/* Assert the reset signal */
 	phy_device_reset(phydev, 1);
-
 	mdiobus_unregister_device(&phydev->mdio);
 	return err;
 }
+
+/**
+ * phy_device_register_locked - Register the phy device on the MDIO bus
+ * @phydev: phy_device structure to be added to the MDIO bus
+ *
+ * Same as phy_device_register() but caller must already hold rtnl_lock().
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int phy_device_register_locked(struct phy_device *phydev)
+{
+	int err;
+
+	ASSERT_RTNL();
+
+	err = __phy_device_register(phydev);
+	if (err)
+		return err;
+
+	mutex_lock(&phy_pse_lock);
+	phy_try_attach_pse(phydev);
+	mutex_unlock(&phy_pse_lock);
+
+	return 0;
+}
+EXPORT_SYMBOL(phy_device_register_locked);
+
+/**
+ * phy_device_register - Register the phy device on the MDIO bus
+ * @phydev: phy_device structure to be added to the MDIO bus
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int phy_device_register(struct phy_device *phydev)
+{
+	int err;
+
+	err = __phy_device_register(phydev);
+	if (err)
+		return err;
+
+	mutex_lock(&phy_pse_lock);
+	phy_try_attach_pse(phydev);
+	mutex_unlock(&phy_pse_lock);
+
+	return 0;
+}
 EXPORT_SYMBOL(phy_device_register);
 
 /**
@@ -1152,7 +1315,15 @@ EXPORT_SYMBOL(phy_device_register);
 void phy_device_remove(struct phy_device *phydev)
 {
 	unregister_mii_timestamper(phydev->mii_ts);
+
+	/* Detach synchronously, before the phy leaves the bus, so the put cannot
+	 * outlive the PSE controller (an off-bus but still-pinned phy is missed by
+	 * the PSE_UNREGISTERED walk). phy_pse_lock serialises against that walk.
+	 */
+	mutex_lock(&phy_pse_lock);
 	pse_control_put(phydev->psec);
+	phydev->psec = NULL;
+	mutex_unlock(&phy_pse_lock);
 
 	device_del(&phydev->mdio.dev);
 
@@ -3981,8 +4152,14 @@ static int __init phy_init(void)
 	if (rc)
 		goto err_c45;
 
+	rc = pse_register_notifier(&phy_pse_notifier);
+	if (rc)
+		goto err_genphy;
+
 	return 0;
 
+err_genphy:
+	phy_driver_unregister(&genphy_driver);
 err_c45:
 	phy_driver_unregister(&genphy_c45_driver);
 err_ethtool_phy_ops:
@@ -3999,6 +4176,7 @@ static int __init phy_init(void)
 
 static void __exit phy_exit(void)
 {
+	pse_unregister_notifier(&phy_pse_notifier);
 	phy_driver_unregister(&genphy_c45_driver);
 	phy_driver_unregister(&genphy_driver);
 	rtnl_lock();
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 03bfd8640db96..18868bdd64852 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -2083,7 +2083,7 @@ static int sfp_sm_probe_phy(struct sfp *sfp, int addr, bool is_c45)
 	/* Mark this PHY as being on a SFP module */
 	phy->is_on_sfp_module = true;
 
-	err = phy_device_register(phy);
+	err = phy_device_register_locked(phy);
 	if (err) {
 		phy_device_free(phy);
 		dev_err(sfp->dev, "phy_device_register failed: %pe\n",
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 69dbdbde9d71a..611540df43bb1 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -8,6 +8,7 @@
 #include <linux/device.h>
 #include <linux/ethtool.h>
 #include <linux/ethtool_netlink.h>
+#include <linux/notifier.h>
 #include <linux/of.h>
 #include <linux/phy.h>
 #include <linux/pse-pd/pse.h>
@@ -23,6 +24,39 @@ static LIST_HEAD(pse_controller_list);
 static DEFINE_XARRAY_ALLOC(pse_pw_d_map);
 static DEFINE_MUTEX(pse_pw_d_mutex);
 
+static BLOCKING_NOTIFIER_HEAD(pse_controller_notifier);
+
+/**
+ * pse_register_notifier - register a callback for PSE controller events
+ * @nb: notifier block to register
+ *
+ * See enum pse_controller_event for events fired and their subscriber
+ * contract. Callbacks run in process context; they may sleep, take
+ * rtnl, and call of_pse_control_get(). The chain fires synchronously,
+ * so a PSE controller driver's probe/unbind path must not hold any
+ * such lock when calling pse_controller_register() or
+ * pse_controller_unregister().
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+int pse_register_notifier(struct notifier_block *nb)
+{
+	return blocking_notifier_chain_register(&pse_controller_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(pse_register_notifier);
+
+/**
+ * pse_unregister_notifier - unregister a previously registered callback
+ * @nb: notifier block previously passed to pse_register_notifier()
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+int pse_unregister_notifier(struct notifier_block *nb)
+{
+	return blocking_notifier_chain_unregister(&pse_controller_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(pse_unregister_notifier);
+
 /**
  * struct pse_control - a PSE control
  * @pcdev: a pointer to the PSE controller device
@@ -1104,6 +1138,9 @@ int pse_controller_register(struct pse_controller_dev *pcdev)
 	list_add(&pcdev->list, &pse_controller_list);
 	mutex_unlock(&pse_list_mutex);
 
+	blocking_notifier_call_chain(&pse_controller_notifier,
+				     PSE_REGISTERED, pcdev);
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(pse_controller_register);
@@ -1114,6 +1151,9 @@ EXPORT_SYMBOL_GPL(pse_controller_register);
  */
 void pse_controller_unregister(struct pse_controller_dev *pcdev)
 {
+	blocking_notifier_call_chain(&pse_controller_notifier,
+				     PSE_UNREGISTERED, pcdev);
+
 	pse_flush_pw_ds(pcdev);
 	pse_release_pis(pcdev);
 	if (pcdev->irq)
@@ -1981,3 +2021,17 @@ bool pse_has_c33(struct pse_control *psec)
 	return psec->pcdev->types & ETHTOOL_PSE_C33;
 }
 EXPORT_SYMBOL_GPL(pse_has_c33);
+
+/**
+ * pse_control_matches_pcdev - Test whether a pse_control targets a controller
+ * @psec: pse_control obtained from of_pse_control_get()
+ * @pcdev: PSE controller to compare against
+ *
+ * Return: %true if @psec was obtained from @pcdev, %false otherwise.
+ */
+bool pse_control_matches_pcdev(struct pse_control *psec,
+			       struct pse_controller_dev *pcdev)
+{
+	return psec->pcdev == pcdev;
+}
+EXPORT_SYMBOL_GPL(pse_control_matches_pcdev);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 199a7aaa341bf..55a0049c6c2b5 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -2158,8 +2158,12 @@ struct phy_device *fwnode_phy_find_device(struct fwnode_handle *phy_fwnode);
 struct fwnode_handle *fwnode_get_phy_node(const struct fwnode_handle *fwnode);
 struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
 int phy_device_register(struct phy_device *phy);
+/* Caller must hold rtnl_lock(); see phy_device_register() for the public form. */
+int phy_device_register_locked(struct phy_device *phy);
 void phy_device_free(struct phy_device *phydev);
 void phy_device_remove(struct phy_device *phydev);
+void phy_pse_control_lock(void);
+void phy_pse_control_unlock(void);
 int phy_get_c45_ids(struct phy_device *phydev);
 int phy_init_hw(struct phy_device *phydev);
 int phy_suspend(struct phy_device *phydev);
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index 4e5696cfade7c..d4310ca71a3e0 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -21,6 +21,7 @@ struct net_device;
 struct phy_device;
 struct pse_controller_dev;
 struct netlink_ext_ack;
+struct notifier_block;
 
 /* C33 PSE extended state and substate. */
 struct ethtool_c33_pse_ext_state_info {
@@ -337,6 +338,24 @@ enum pse_budget_eval_strategies {
 	PSE_BUDGET_EVAL_STRAT_DYNAMIC	= 1 << 2,
 };
 
+/**
+ * enum pse_controller_event - PSE controller lifecycle events
+ *
+ * Event data in callbacks is always a pointer to the struct
+ * pse_controller_dev firing the event.
+ *
+ * @PSE_REGISTERED: controller added to pse_controller_list and
+ *	resolvable by of_pse_control_get().
+ * @PSE_UNREGISTERED: controller about to be removed from
+ *	pse_controller_list. Subscribers holding pse_control references
+ *	targeting it must drop them before returning and must not
+ *	acquire new references for it.
+ */
+enum pse_controller_event {
+	PSE_REGISTERED,
+	PSE_UNREGISTERED,
+};
+
 #if IS_ENABLED(CONFIG_PSE_CONTROLLER)
 int pse_controller_register(struct pse_controller_dev *pcdev);
 void pse_controller_unregister(struct pse_controller_dev *pcdev);
@@ -366,6 +385,12 @@ int pse_ethtool_set_prio(struct pse_control *psec,
 bool pse_has_podl(struct pse_control *psec);
 bool pse_has_c33(struct pse_control *psec);
 
+bool pse_control_matches_pcdev(struct pse_control *psec,
+			       struct pse_controller_dev *pcdev);
+
+int pse_register_notifier(struct notifier_block *nb);
+int pse_unregister_notifier(struct notifier_block *nb);
+
 #else
 
 static inline struct pse_control *of_pse_control_get(struct device_node *node,
@@ -416,6 +441,22 @@ static inline bool pse_has_c33(struct pse_control *psec)
 	return false;
 }
 
+static inline bool pse_control_matches_pcdev(struct pse_control *psec,
+					     struct pse_controller_dev *pcdev)
+{
+	return false;
+}
+
+static inline int pse_register_notifier(struct notifier_block *nb)
+{
+	return 0;
+}
+
+static inline int pse_unregister_notifier(struct notifier_block *nb)
+{
+	return 0;
+}
+
 #endif
 
 #endif
diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
index 757c9e0cc856f..4edd9a514de14 100644
--- a/net/ethtool/pse-pd.c
+++ b/net/ethtool/pse-pd.c
@@ -71,7 +71,9 @@ static int pse_prepare_data(const struct ethnl_req_info *req_base,
 	if (ret < 0)
 		return ret;
 
+	phy_pse_control_lock();
 	ret = pse_get_pse_attributes(phydev, info->extack, data);
+	phy_pse_control_unlock();
 
 	ethnl_ops_complete(dev);
 
@@ -281,9 +283,12 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 
 	phydev = ethnl_req_get_phydev(req_info, tb, ETHTOOL_A_PSE_HEADER,
 				      info->extack);
+
+	phy_pse_control_lock();
+
 	ret = ethnl_set_pse_validate(phydev, info);
 	if (ret)
-		return ret;
+		goto out;
 
 	if (tb[ETHTOOL_A_PSE_PRIO]) {
 		unsigned int prio;
@@ -291,7 +296,7 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 		prio = nla_get_u32(tb[ETHTOOL_A_PSE_PRIO]);
 		ret = pse_ethtool_set_prio(phydev->psec, info->extack, prio);
 		if (ret)
-			return ret;
+			goto out;
 	}
 
 	if (tb[ETHTOOL_A_C33_PSE_AVAIL_PW_LIMIT]) {
@@ -301,7 +306,7 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 		ret = pse_ethtool_set_pw_limit(phydev->psec, info->extack,
 					       pw_limit);
 		if (ret)
-			return ret;
+			goto out;
 	}
 
 	/* These values are already validated by the ethnl_pse_set_policy */
@@ -319,11 +324,11 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 		 */
 		ret = pse_ethtool_set_config(phydev->psec, info->extack,
 					     &config);
-		if (ret)
-			return ret;
 	}
 
+out:
 	/* Return errno or zero - PSE has no notification */
+	phy_pse_control_unlock();
 	return ret;
 }
 

gemini-3.1-pro-preview

null

null

							input: 8375
							output: 26
							thoughts: 409
						

**Analyzing the PSE Control Patch**

Okay, so I'm looking at this patch that's refactoring how the `pse_control` is handled in relation to `phy_device`. They're introducing a `phy_pse_lock` mutex and a notifier, `phy_pse_notifier`, for `PSE_REGISTERED` and `PSE_UNREGISTERED` events. Smart move; that adds some much-needed thread safety. They've also updated `ethtool` to use the lock/unlock around `phydev->psec` accesses. I see the code touches `drivers/net/phy/phy_device.c`, `drivers/net/phy/sfp.c`, `drivers/net/pse-pd/pse_core.c`, plus some headers. Good, they've covered the key areas.

My main concern is whether this functionality is testable, especially in a virtualized environment. Let's see... `phy_device.c` is the core PHY library, and `ethtool/pse-pd.c` is the ethtool netlink interface for PSE. And `pse-core.c` is the PSE core itself. So, can we actually reach the PSE core?

Right, the key is whether we can exercise it. Let's dig into `ethtool/pse-pd.c` and `pse_core.c`. This is all part of the PoE landscape, Power over Ethernet. Can we trigger it through the ethtool netlink interface? Ah, yes, `ethnl_set_pse` is an ethtool netlink command. That's a good entry point. Now, to trigger the notifier, we need a PSE controller to register or unregister. That's the crux of it.

So, the question now is, are there any software emulated PSE controllers? Or can we somehow trigger a registration/unregistration using some kind of dummy driver? Time to explore the `drivers/net/pse-pd/` directory and see if anything jumps out. I need to figure out how to simulate those registration and unregistration events for proper testing.

{
  "Dir": "drivers/net/pse-pd/"
}

{
  "Files": [
    "pd692x0.c",
    "pse_core.c",
    "pse_regulator.c",
    "si3474.c",
    "tps23881.c"
  ],
  "Subdirs": null
}

gemini-3.1-pro-preview

null

null

							input: 9327
							output: 38
							thoughts: 78
						

**Initial Assessment of Power Drivers**

Okay, so I'm looking at these power driver files: `pd692x0.c`, `pse_regulator.c`, `si3474.c`, and `tps23881.c`. My first thought is to quickly see which ones are worth further investigation and how they might fit into the system architecture. `pse_regulator.c` has a distinct possibility of being handled through either the device tree or direct software instantiation. This merits immediate attention. Let's dive into `pse_regulator.c` first to see what the options are there. I'm hoping it's well-structured and follows a modern approach.

no matches

{
  "Expression": "pse_regulator",
  "PathPrefix": "drivers/net/pse-pd/pse_regulator.c"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 9609
							output: 41
							thoughts: 9
						

Okay, here's the summary, rendered as your internal monologue:

**Focus: Strategic Simplification**

Right, instead of overcomplicating this or going down some rabbit hole of initial analysis, I should just... *read the file*. That’s the most direct route. It's too easy to get caught up in premature optimization or trying to anticipate every possible outcome. Just go directly to the source. Get a baseline understanding of the data or the code or whatever's in that file. That simple act is the right first step. Don't overthink it, let the file reveal what's important, then I can adjust accordingly.

{
  "File": "drivers/net/pse-pd/pse_regulator.c",
  "FirstLine": 1,
  "LineCount": 100
}

{
  "Contents": "   1:\t// SPDX-License-Identifier: GPL-2.0-only\n   2:\t//\n   3:\t// Driver for the regulator based Ethernet Power Sourcing Equipment, without\n   4:\t// auto classification support.\n   5:\t//\n   6:\t// Copyright (c) 2022 Pengutronix, Oleksij Rempel \u003ckernel@pengutronix.de\u003e\n   7:\t//\n   8:\t\n   9:\t#include \u003clinux/module.h\u003e\n  10:\t#include \u003clinux/of.h\u003e\n  11:\t#include \u003clinux/platform_device.h\u003e\n  12:\t#include \u003clinux/pse-pd/pse.h\u003e\n  13:\t#include \u003clinux/regulator/consumer.h\u003e\n  14:\t\n  15:\tstruct pse_reg_priv {\n  16:\t\tstruct pse_controller_dev pcdev;\n  17:\t\tstruct regulator *ps; /*power source */\n  18:\t\tenum ethtool_podl_pse_admin_state admin_state;\n  19:\t};\n  20:\t\n  21:\tstatic struct pse_reg_priv *to_pse_reg(struct pse_controller_dev *pcdev)\n  22:\t{\n  23:\t\treturn container_of(pcdev, struct pse_reg_priv, pcdev);\n  24:\t}\n  25:\t\n  26:\tstatic int\n  27:\tpse_reg_pi_enable(struct pse_controller_dev *pcdev, int id)\n  28:\t{\n  29:\t\tstruct pse_reg_priv *priv = to_pse_reg(pcdev);\n  30:\t\tint ret;\n  31:\t\n  32:\t\tret = regulator_enable(priv-\u003eps);\n  33:\t\tif (ret)\n  34:\t\t\treturn ret;\n  35:\t\n  36:\t\tpriv-\u003eadmin_state = ETHTOOL_PODL_PSE_ADMIN_STATE_ENABLED;\n  37:\t\treturn 0;\n  38:\t}\n  39:\t\n  40:\tstatic int\n  41:\tpse_reg_pi_disable(struct pse_controller_dev *pcdev, int id)\n  42:\t{\n  43:\t\tstruct pse_reg_priv *priv = to_pse_reg(pcdev);\n  44:\t\tint ret;\n  45:\t\n  46:\t\tret = regulator_disable(priv-\u003eps);\n  47:\t\tif (ret)\n  48:\t\t\treturn ret;\n  49:\t\n  50:\t\tpriv-\u003eadmin_state = ETHTOOL_PODL_PSE_ADMIN_STATE_DISABLED;\n  51:\t\treturn 0;\n  52:\t}\n  53:\t\n  54:\tstatic int\n  55:\tpse_reg_pi_get_admin_state(struct pse_controller_dev *pcdev, int id,\n  56:\t\t\t\t   struct pse_admin_state *admin_state)\n  57:\t{\n  58:\t\tstruct pse_reg_priv *priv = to_pse_reg(pcdev);\n  59:\t\n  60:\t\tadmin_state-\u003epodl_admin_state = priv-\u003eadmin_state;\n  61:\t\n  62:\t\treturn 0;\n  63:\t}\n  64:\t\n  65:\tstatic int\n  66:\tpse_reg_pi_get_pw_status(struct pse_controller_dev *pcdev, int id,\n  67:\t\t\t\t struct pse_pw_status *pw_status)\n  68:\t{\n  69:\t\tstruct pse_reg_priv *priv = to_pse_reg(pcdev);\n  70:\t\tint ret;\n  71:\t\n  72:\t\tret = regulator_is_enabled(priv-\u003eps);\n  73:\t\tif (ret \u003c 0)\n  74:\t\t\treturn ret;\n  75:\t\n  76:\t\tif (!ret)\n  77:\t\t\tpw_status-\u003epodl_pw_status =\n  78:\t\t\t\tETHTOOL_PODL_PSE_PW_D_STATUS_DISABLED;\n  79:\t\telse\n  80:\t\t\tpw_status-\u003epodl_pw_status =\n  81:\t\t\t\tETHTOOL_PODL_PSE_PW_D_STATUS_DELIVERING;\n  82:\t\n  83:\t\treturn 0;\n  84:\t}\n  85:\t\n  86:\tstatic const struct pse_controller_ops pse_reg_ops = {\n  87:\t\t.pi_get_admin_state = pse_reg_pi_get_admin_state,\n  88:\t\t.pi_get_pw_status = pse_reg_pi_get_pw_status,\n  89:\t\t.pi_enable = pse_reg_pi_enable,\n  90:\t\t.pi_disable = pse_reg_pi_disable,\n  91:\t};\n  92:\t\n  93:\tstatic int\n  94:\tpse_reg_probe(struct platform_device *pdev)\n  95:\t{\n  96:\t\tstruct device *dev = \u0026pdev-\u003edev;\n  97:\t\tstruct pse_reg_priv *priv;\n  98:\t\tint ret;\n  99:\t\n 100:\t\tpriv = devm_kzalloc(\u0026pdev-\u003edev, sizeof(*priv), GFP_KERNEL);\n"
}

gemini-3.1-pro-preview

null

null

							input: 11157
							output: 40
							thoughts: 83
						

**Platform Device Driver Deep Dive**

Okay, so I'm looking at this; it seems to be a platform device driver. My immediate thought is, "Can we utilize `ethtool` commands on a PHY device directly?" My experience tells me that, yes, we *could* achieve this by employing a dummy network device that's associated with the PHY. That's a good approach to take. But then, a red flag – and it's an important one – pops up: `ethnl_set_pse`. Wait a second… that's an ethtool netlink command. Now, I need to trace this back. Let's see... the most likely source would be `net/ethtool/pse-pd.c`. Time to dig into that and see how they are related.

{
  "File": "net/ethtool/pse-pd.c",
  "FirstLine": 275,
  "LineCount": 100
}

{
  "Contents": " 275:\t}\n 276:\t\n 277:\tstatic int\n 278:\tethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)\n 279:\t{\n 280:\t\tstruct nlattr **tb = info-\u003eattrs;\n 281:\t\tstruct phy_device *phydev;\n 282:\t\tint ret;\n 283:\t\n 284:\t\tphydev = ethnl_req_get_phydev(req_info, tb, ETHTOOL_A_PSE_HEADER,\n 285:\t\t\t\t\t      info-\u003eextack);\n 286:\t\n 287:\t\tphy_pse_control_lock();\n 288:\t\n 289:\t\tret = ethnl_set_pse_validate(phydev, info);\n 290:\t\tif (ret)\n 291:\t\t\tgoto out;\n 292:\t\n 293:\t\tif (tb[ETHTOOL_A_PSE_PRIO]) {\n 294:\t\t\tunsigned int prio;\n 295:\t\n 296:\t\t\tprio = nla_get_u32(tb[ETHTOOL_A_PSE_PRIO]);\n 297:\t\t\tret = pse_ethtool_set_prio(phydev-\u003epsec, info-\u003eextack, prio);\n 298:\t\t\tif (ret)\n 299:\t\t\t\tgoto out;\n 300:\t\t}\n 301:\t\n 302:\t\tif (tb[ETHTOOL_A_C33_PSE_AVAIL_PW_LIMIT]) {\n 303:\t\t\tunsigned int pw_limit;\n 304:\t\n 305:\t\t\tpw_limit = nla_get_u32(tb[ETHTOOL_A_C33_PSE_AVAIL_PW_LIMIT]);\n 306:\t\t\tret = pse_ethtool_set_pw_limit(phydev-\u003epsec, info-\u003eextack,\n 307:\t\t\t\t\t\t       pw_limit);\n 308:\t\t\tif (ret)\n 309:\t\t\t\tgoto out;\n 310:\t\t}\n 311:\t\n 312:\t\t/* These values are already validated by the ethnl_pse_set_policy */\n 313:\t\tif (tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL] ||\n 314:\t\t    tb[ETHTOOL_A_C33_PSE_ADMIN_CONTROL]) {\n 315:\t\t\tstruct pse_control_config config = {};\n 316:\t\n 317:\t\t\tif (tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL])\n 318:\t\t\t\tconfig.podl_admin_control = nla_get_u32(tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL]);\n 319:\t\t\tif (tb[ETHTOOL_A_C33_PSE_ADMIN_CONTROL])\n 320:\t\t\t\tconfig.c33_admin_control = nla_get_u32(tb[ETHTOOL_A_C33_PSE_ADMIN_CONTROL]);\n 321:\t\n 322:\t\t\t/* pse_ethtool_set_config() will do nothing if the config\n 323:\t\t\t * is zero\n 324:\t\t\t */\n 325:\t\t\tret = pse_ethtool_set_config(phydev-\u003epsec, info-\u003eextack,\n 326:\t\t\t\t\t\t     \u0026config);\n 327:\t\t}\n 328:\t\n 329:\tout:\n 330:\t\t/* Return errno or zero - PSE has no notification */\n 331:\t\tphy_pse_control_unlock();\n 332:\t\treturn ret;\n 333:\t}\n 334:\t\n 335:\tconst struct ethnl_request_ops ethnl_pse_request_ops = {\n 336:\t\t.request_cmd\t\t= ETHTOOL_MSG_PSE_GET,\n 337:\t\t.reply_cmd\t\t= ETHTOOL_MSG_PSE_GET_REPLY,\n 338:\t\t.hdr_attr\t\t= ETHTOOL_A_PSE_HEADER,\n 339:\t\t.req_info_size\t\t= sizeof(struct pse_req_info),\n 340:\t\t.reply_data_size\t= sizeof(struct pse_reply_data),\n 341:\t\n 342:\t\t.prepare_data\t\t= pse_prepare_data,\n 343:\t\t.reply_size\t\t= pse_reply_size,\n 344:\t\t.fill_reply\t\t= pse_fill_reply,\n 345:\t\t.cleanup_data\t\t= pse_cleanup_data,\n 346:\t\n 347:\t\t.set\t\t\t= ethnl_set_pse,\n 348:\t\t/* PSE has no notification */\n 349:\t};\n 350:\t\n 351:\tvoid ethnl_pse_send_ntf(struct net_device *netdev, unsigned long notifs)\n 352:\t{\n 353:\t\tvoid *reply_payload;\n 354:\t\tstruct sk_buff *skb;\n 355:\t\tint reply_len;\n 356:\t\tint ret;\n 357:\t\n 358:\t\tASSERT_RTNL();\n 359:\t\n 360:\t\tif (!netdev || !notifs)\n 361:\t\t\treturn;\n 362:\t\n 363:\t\treply_len = ethnl_reply_header_size() +\n 364:\t\t\t    nla_total_size(sizeof(u32)); /* _PSE_NTF_EVENTS */\n 365:\t\n 366:\t\tskb = genlmsg_new(reply_len, GFP_KERNEL);\n 367:\t\tif (!skb)\n 368:\t\t\treturn;\n 369:\t\n 370:\t\treply_payload = ethnl_bcastmsg_put(skb, ETHTOOL_MSG_PSE_NTF);\n 371:\t\tif (!reply_payload)\n 372:\t\t\tgoto err_skb;\n 373:\t\n 374:\t\tret = ethnl_fill_reply_header(skb, netdev, ETHTOOL_A_PSE_NTF_HEADER);\n"
}

gemini-3.1-pro-preview

null

null

							input: 13079
							output: 37
							thoughts: 739
						

**Initial Assessment of the Code Modification**

Okay, so `ethnl_set_pse` is definitely reachable – that's the starting point. The patch touches `phy_device_register`, `phy_device_remove`, and `phy_device_register_locked`, all core functions for PHY device registration. This is significant because PHY registration is fundamental. We can definitely create an environment where these functions are called, even in QEMU, through `macb`, `e1000`, or other emulated NICs, and possibly through dummy PHYs, as a starting point.

The `phy_pse_notifier` is introduced and registered in `phy_init`. The notifier itself is triggered by `pse_controller_register` and `pse_controller_unregister`. The key question is whether we can trigger `pse_controller_register` at all. Loading a PSE driver is the obvious route, but those are typically platform drivers. Could there be a way to force a registration from userspace, perhaps via device tree overlays? Maybe a dummy PSE driver is the answer.

But hold on, the notifier gets triggered on *registration* of a PSE controller. The important thing is that, even if getting a PSE controller registered is difficult, the `ETHTOOL_MSG_PSE_GET` and `ETHTOOL_MSG_PSE_SET` netlink commands, which utilize `ethnl_set_pse`, are reachable and now use `phy_pse_control_lock()`. Also, we have the original `phy_device_register` and `phy_device_remove` which also use `phy_pse_lock`. So, this is a core functional change in the PHY library and ethtool. It's definitely ripe for fuzzing.

**Target Functions**

Now, let's identify the key functions to target:

*   `phy_try_attach_pse`
*   `phy_pse_attach_one`
*   `phy_pse_detach_one`
*   `phy_pse_notifier_event`
*   `phy_pse_control_lock`
*   `phy_pse_control_unlock`
*   `__phy_device_register`
*   `phy_device_register_locked`
*   `phy_device_register`
*   `phy_device_remove`
*   `pse_register_notifier`
*   `pse_unregister_notifier`
*   `pse_controller_register`
*   `pse_controller_unregister`
*   `pse_control_matches_pcdev`
*   `ethnl_set_pse`
*   `pse_prepare_data`

**Configuration Dependency Check**

We need to understand the configuration implications. The `include/linux/pse-pd/pse.h` file reveals that `pse_controller_register`, `pse_controller_unregister`, `pse_register_notifier` and `pse_unregister_notifier` are only defined if `CONFIG_PSE_CONTROLLER` is enabled. If not enabled, these functions probably resolve to empty (inline) functions or return early.

However, because `phy_init` calls `pse_register_notifier` without checking for the config option, even if `CONFIG_PSE_CONTROLLER` isn't set, `phy_init` will still be called. It will call the empty/inline `pse_register_notifier`, which will return 0 and continue.

So, to test the actual notifier registration and chain, we *need* to enable `CONFIG_PSE_CONTROLLER`. We should check the Kconfig in `drivers/net/pse-pd/Kconfig` for related configuration.

{
  "File": "drivers/net/pse-pd/Kconfig",
  "FirstLine": 1,
  "LineCount": 100
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0-only\n   2:\t#\n   3:\t# Ethernet Power Sourcing Equipment drivers\n   4:\t#\n   5:\t\n   6:\tmenuconfig PSE_CONTROLLER\n   7:\t\tbool \"Ethernet Power Sourcing Equipment Support\"\n   8:\t\tdepends on REGULATOR\n   9:\t\thelp\n  10:\t\t  Generic Power Sourcing Equipment Controller support.\n  11:\t\n  12:\t\t  If unsure, say no.\n  13:\t\n  14:\tif PSE_CONTROLLER\n  15:\t\n  16:\tconfig PSE_REGULATOR\n  17:\t\ttristate \"Regulator based PSE controller\"\n  18:\t\thelp\n  19:\t\t  This module provides support for simple regulator based Ethernet Power\n  20:\t\t  Sourcing Equipment without automatic classification support. For\n  21:\t\t  example for basic implementation of PoDL (802.3bu) specification.\n  22:\t\n  23:\tconfig PSE_PD692X0\n  24:\t\ttristate \"PD692X0 PSE controller\"\n  25:\t\tdepends on I2C\n  26:\t\tselect FW_LOADER\n  27:\t\tselect FW_UPLOAD\n  28:\t\thelp\n  29:\t\t  This module provides support for PD692x0 regulator based Ethernet\n  30:\t\t  Power Sourcing Equipment.\n  31:\t\n  32:\t\t  To compile this driver as a module, choose M here: the\n  33:\t\t  module will be called pd692x0.\n  34:\t\n  35:\tconfig PSE_SI3474\n  36:\t\ttristate \"Si3474 PSE controller\"\n  37:\t\tdepends on I2C\n  38:\t\thelp\n  39:\t\t  This module provides support for Si3474 regulator based Ethernet\n  40:\t\t  Power Sourcing Equipment.\n  41:\t\t  Only 4-pair PSE configurations are supported.\n  42:\t\n  43:\t\t  To compile this driver as a module, choose M here: the\n  44:\t\t  module will be called si3474.\n  45:\t\n  46:\tconfig PSE_TPS23881\n  47:\t\ttristate \"TPS23881 PSE controller\"\n  48:\t\tdepends on I2C\n  49:\t\thelp\n  50:\t\t  This module provides support for TPS23881 regulator based Ethernet\n  51:\t\t  Power Sourcing Equipment.\n  52:\t\n  53:\t\t  To compile this driver as a module, choose M here: the\n  54:\t\t  module will be called tps23881.\n  55:\tendif\n"
}

gemini-3.1-pro-preview

null

null

							input: 15346
							output: 29
							thoughts: 200
						

**My Configuration Considerations**

Okay, so I'm looking at this configuration, and it's pretty straightforward. `PSE_CONTROLLER` depends on `REGULATOR`, so naturally, I need to enable both. But then I remember `PSE_CONTROLLER` is just a boolean; it's on or off. That makes things a bit simpler.

I need to see if we have a dummy PSE driver or if enabling `PSE_REGULATOR` will give us one. Ah, good, `PSE_REGULATOR` is `tristate`. So, I *can* enable it. That settles it: my `EnableConfigs` list needs to include `PSE_CONTROLLER` and `REGULATOR`. Easy peasy.

Now, just to be thorough, I'm going to quickly check `net/ethtool/pse-pd.c`. I'm guessing that code has some dependency on `PSE_CONTROLLER`, or at the very least, those ethtool PSE commands are always compiled if `ETHTOOL_NETLINK` is enabled, even if they return an error if `PSE_CONTROLLER` is not. Just to confirm my assumptions, I'll take a quick look at `net/ethtool/Makefile`.

{
  "Expression": "pse-pd",
  "PathPrefix": "net/ethtool/"
}

{
  "Output": "net/ethtool/Makefile=7=ethtool_nl-y\t:= netlink.o bitset.o strset.o linkinfo.o linkmodes.o rss.o \\\n--\nnet/ethtool/Makefile-10-\t\t   tunnels.o fec.o eeprom.o stats.o phc_vclocks.o mm.o \\\nnet/ethtool/Makefile:11:\t\t   module.o cmis_fw_update.o cmis_cdb.o pse-pd.o plca.o \\\nnet/ethtool/Makefile-12-\t\t   phy.o tsconfig.o mse.o\n--\nnet/ethtool/pse-pd.c-14-#include \"common.h\"\nnet/ethtool/pse-pd.c:15:#include \"linux/pse-pd/pse.h\"\nnet/ethtool/pse-pd.c-16-#include \"netlink.h\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 16083
							output: 38
							thoughts: 234
						

**My Analysis of PSE Compilation Dependencies**

Okay, so I'm confirming that `pse-pd.o` is indeed always compiled when `ethtool_nl-y` is included, which makes sense given my understanding of the codebase. Now, I need to pinpoint the key symbols involved in this `pse` functionality. Let's see...

I'm making a mental list of the core symbols. I'm going to track `phy_try_attach_pse`, but it's *static* which means it might get inlined, so I'll be sure to also make a note of the functions that call it: `phy_pse_attach_one`, `phy_device_register_locked`, and `phy_device_register`. I'll probably focus on the non-static ones since the inlining will mean the actual symbol might not be available at runtime. The others on my list are: `phy_pse_control_lock`, `phy_pse_control_unlock`, `phy_device_register_locked`, `phy_device_register`, `phy_device_remove`, `pse_register_notifier`, `pse_unregister_notifier`, `pse_controller_register`, `pse_controller_unregister`, `pse_control_matches_pcdev`, `ethnl_set_pse`, and `pse_prepare_data`.

I'll start by taking a closer look at `phy_device_register_locked` and `phy_device_register` to see how those integrate.

{
  "Expression": "phy_device_register_locked",
  "PathPrefix": "drivers/net/phy/phy_device.c"
}

{
  "Output": "drivers/net/phy/phy_device.c=1226=static int __phy_device_register(struct phy_device *phydev)\n--\ndrivers/net/phy/phy_device.c-1259-/**\ndrivers/net/phy/phy_device.c:1260: * phy_device_register_locked - Register the phy device on the MDIO bus\ndrivers/net/phy/phy_device.c-1261- * @phydev: phy_device structure to be added to the MDIO bus\n--\ndrivers/net/phy/phy_device.c-1266- */\ndrivers/net/phy/phy_device.c:1267:int phy_device_register_locked(struct phy_device *phydev)\ndrivers/net/phy/phy_device.c-1268-{\n--\ndrivers/net/phy/phy_device.c-1282-}\ndrivers/net/phy/phy_device.c:1283:EXPORT_SYMBOL(phy_device_register_locked);\ndrivers/net/phy/phy_device.c-1284-\n"
}

gemini-3.1-pro-preview

null

null

							input: 16960
							output: 37
							thoughts: 126
						

**Examining the PHY and PSE Exports**

Okay, so I'm double-checking the symbol exports here, and yes, it seems `phy_device_register_locked` is indeed exported, which is good. That's a fundamental PHY function. And just to be absolutely certain, `phy_device_register` is also exported, as I would expect. The removal function, `phy_device_remove`, is also accounted for, so the core PHY registration and deregistration appear to be well-defined.

Moving on to the Power Sourcing Equipment, the PSE side: I see `pse_register_notifier` and `pse_unregister_notifier` exported, which makes sense for handling notifications. And the controller registration and unregistration functions, `pse_controller_register` and `pse_controller_unregister`, are also available. Finally, it appears `pse_control_matches_pcdev` is as well. That’s probably important for matching PSE control with the platform device.

Now, a brief pause. I see that `ethnl_set_pse` is static... hmm. Let me quickly check where that is defined... Ah, right, that's in `net/ethtool/pse-pd.c`. Okay, that makes more sense now.

{
  "Expression": "ethnl_set_pse",
  "PathPrefix": "net/ethtool/pse-pd.c"
}

{
  "Output": "net/ethtool/pse-pd.c=244=static int\nnet/ethtool/pse-pd.c:245:ethnl_set_pse_validate(struct phy_device *phydev, struct genl_info *info)\nnet/ethtool/pse-pd.c-246-{\n--\nnet/ethtool/pse-pd.c=277=static int\nnet/ethtool/pse-pd.c:278:ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)\nnet/ethtool/pse-pd.c-279-{\n--\nnet/ethtool/pse-pd.c-288-\nnet/ethtool/pse-pd.c:289:\tret = ethnl_set_pse_validate(phydev, info);\nnet/ethtool/pse-pd.c-290-\tif (ret)\n--\nnet/ethtool/pse-pd.c=335=const struct ethnl_request_ops ethnl_pse_request_ops = {\n--\nnet/ethtool/pse-pd.c-346-\nnet/ethtool/pse-pd.c:347:\t.set\t\t\t= ethnl_set_pse,\nnet/ethtool/pse-pd.c-348-\t/* PSE has no notification */\n"
}

gemini-3.1-pro-preview

null

null

							input: 17749
							output: 36
							thoughts: 102
						

**Analyzing Network Link Configuration and Potential Symbol Visibility**

Okay, so I'm looking at `ethnl_set_pse`. It's defined as `static`, which usually means it's not meant to be accessed from outside the current compilation unit. However, I see it's assigned to the `.set` member of `ethnl_pse_request_ops`. That's a netlink function pointer. Therefore, even though it's static, it's actually reachable through netlink communication. Interesting.

This means I need to consider `ethnl_set_pse` for inclusion in `FocusSymbols`, assuming it's not inlined by the compiler. Given that it's assigned to a function pointer, I'm pretty confident it *won't* be inlined. Function pointers usually prevent that kind of optimization.

Wait a minute, `pse_prepare_data` is *also* assigned to a function pointer. I need to keep that in mind as well. It could be reachable through the same mechanism. Need to analyze its usage as well.

{
  "Expression": "pse_prepare_data",
  "PathPrefix": "net/ethtool/pse-pd.c"
}

{
  "Output": "net/ethtool/pse-pd.c=36=static int pse_get_pse_attributes(struct phy_device *phydev,\n--\nnet/ethtool/pse-pd.c-54-\nnet/ethtool/pse-pd.c:55:static int pse_prepare_data(const struct ethnl_req_info *req_base,\nnet/ethtool/pse-pd.c-56-\t\t\t    struct ethnl_reply_data *reply_base,\n--\nnet/ethtool/pse-pd.c=335=const struct ethnl_request_ops ethnl_pse_request_ops = {\n--\nnet/ethtool/pse-pd.c-341-\nnet/ethtool/pse-pd.c:342:\t.prepare_data\t\t= pse_prepare_data,\nnet/ethtool/pse-pd.c-343-\t.reply_size\t\t= pse_reply_size,\n"
}

gemini-3.1-pro-preview

null

null

							input: 18360
							output: 38
							thoughts: 26
						

Here's my thought process, as requested:

**Checking Reachability and Event Notification**

Okay, it seems like `pse_prepare_data` is indeed accessible – that's a good starting point. Now, I need to shift my focus to the event notification mechanism. My immediate concern is with `phy_pse_notifier_event`. Understanding how and when this is triggered, and what information it relays, is crucial for [**insert your field/expertise here, e.g., debugging network stack interactions, validating data pipeline integrity, analyzing sensor fusion architecture**]. I need to determine if it's operating as expected and accurately reflecting the state of [**insert relevant system/component here, e.g., the physical layer data stream, the PSE module, the sensor interface**]. This check is critical for [**explain why this is important for your field, e.g., ensuring data integrity across the network, verifying the timing of data processing, validating the synchronization between modules**].

{
  "Expression": "phy_pse_notifier_event",
  "PathPrefix": "drivers/net/phy/phy_device.c"
}

{
  "Output": "drivers/net/phy/phy_device.c=1150=static int phy_pse_detach_one(struct device *dev, void *data)\n--\ndrivers/net/phy/phy_device.c-1170-\ndrivers/net/phy/phy_device.c:1171:static int phy_pse_notifier_event(struct notifier_block *nb,\ndrivers/net/phy/phy_device.c-1172-\t\t\t\t  unsigned long event, void *data)\n--\ndrivers/net/phy/phy_device.c=1192=static struct notifier_block phy_pse_notifier __read_mostly = {\ndrivers/net/phy/phy_device.c:1193:\t.notifier_call = phy_pse_notifier_event,\ndrivers/net/phy/phy_device.c-1194-};\n"
}

gemini-3.1-pro-preview

null

null

							input: 18848
							output: 38
							thoughts: 41
						

Here's your summary:

**Function Pointer Analysis**

Okay, so I'm looking at this code, and the first thing that jumps out is that this operation is assigned to a function pointer. That immediately tells me it's *not* inlined. I need to understand the implications of that for performance and control flow. Knowing it's a pointer means there's an indirection, which can be slower than a direct call, and it also means the compiler might not be able to optimize it as aggressively.

To get a handle on the situation, I need to see what's actually being *pointed* to. I'll need to drill down into the definition of that function pointer. That means I need to investigate the functions where this thing is used. Let's start by looking at `phy_pse_attach_one` and `phy_pse_detach_one`. Examining these functions should reveal the concrete functions that this function pointer is actually set to. This will help clarify the overall design and any potential performance bottlenecks.

{
  "Expression": "phy_pse_attach_one",
  "PathPrefix": "drivers/net/phy/phy_device.c"
}

{
  "Output": "drivers/net/phy/phy_device.c=1114=static void phy_try_attach_pse(struct phy_device *phydev)\n--\ndrivers/net/phy/phy_device.c-1138-\ndrivers/net/phy/phy_device.c:1139:static int phy_pse_attach_one(struct device *dev, void *data __maybe_unused)\ndrivers/net/phy/phy_device.c-1140-{\n--\ndrivers/net/phy/phy_device.c=1171=static int phy_pse_notifier_event(struct notifier_block *nb,\n--\ndrivers/net/phy/phy_device.c-1177-\t\tbus_for_each_dev(\u0026mdio_bus_type, NULL, NULL,\ndrivers/net/phy/phy_device.c:1178:\t\t\t\t phy_pse_attach_one);\ndrivers/net/phy/phy_device.c-1179-\t\tmutex_unlock(\u0026phy_pse_lock);\n"
}

gemini-3.1-pro-preview

null

null

							input: 19404
							output: 38
							thoughts: 34
						

Okay, here's my interpretation of those thoughts, presented as a first-person expert summary:

**Analyzing Device Attachment in a PHY Context**

Right, so these device attachment operations aren't inlined, they are being passed to `bus_for_each_dev`. That tells me we're likely dealing with a bus-based enumeration and not something happening within the confines of a single function call. This is important context, particularly when trying to grasp the scope of potential side effects and interactions. Since it's iterating, this probably means there are multiple devices or sub-devices being handled during attachment.

Given the context, the next logical step in understanding the device attachment process is to examine `phy_try_attach_pse`. I should dive into that function now to see how the Physical Layer device (PHY) attempts to connect to or interact with something it calls "PSE," likely Power Sourcing Equipment, particularly since we're not dealing with inline code. Understanding the role of the PSE during device attachment will provide critical insights into the power management aspect and how these devices are integrated.

{
  "Expression": "phy_try_attach_pse",
  "PathPrefix": "drivers/net/phy/phy_device.c"
}

{
  "Output": "drivers/net/phy/phy_device.c=1106=static DEFINE_MUTEX(phy_pse_lock);\n--\ndrivers/net/phy/phy_device.c-1113- */\ndrivers/net/phy/phy_device.c:1114:static void phy_try_attach_pse(struct phy_device *phydev)\ndrivers/net/phy/phy_device.c-1115-{\n--\ndrivers/net/phy/phy_device.c=1139=static int phy_pse_attach_one(struct device *dev, void *data __maybe_unused)\n--\ndrivers/net/phy/phy_device.c-1145-\ndrivers/net/phy/phy_device.c:1146:\tphy_try_attach_pse(to_phy_device(dev));\ndrivers/net/phy/phy_device.c-1147-\treturn 0;\n--\ndrivers/net/phy/phy_device.c=1267=int phy_device_register_locked(struct phy_device *phydev)\n--\ndrivers/net/phy/phy_device.c-1277-\tmutex_lock(\u0026phy_pse_lock);\ndrivers/net/phy/phy_device.c:1278:\tphy_try_attach_pse(phydev);\ndrivers/net/phy/phy_device.c-1279-\tmutex_unlock(\u0026phy_pse_lock);\n--\ndrivers/net/phy/phy_device.c=1291=int phy_device_register(struct phy_device *phydev)\n--\ndrivers/net/phy/phy_device.c-1299-\tmutex_lock(\u0026phy_pse_lock);\ndrivers/net/phy/phy_device.c:1300:\tphy_try_attach_pse(phydev);\ndrivers/net/phy/phy_device.c-1301-\tmutex_unlock(\u0026phy_pse_lock);\n"
}

gemini-3.1-pro-preview

null

null

							input: 20193
							output: 37
							thoughts: 33
						

Okay, here's my interpretation of those thoughts, tailored for an expert audience:

**Analyzing Code Flow: Skipping the Inlined**

Right, this looks like a straightforward, statically defined call. It's likely inlined by the compiler for efficiency. No need to dig into it here; the compiler's probably taken care of it. Let's move on and get to the important part. My next focus is going to be on the `__phy_device_register` function and how it works.

{
  "Expression": "__phy_device_register",
  "PathPrefix": "drivers/net/phy/phy_device.c"
}

{
  "Output": "drivers/net/phy/phy_device.c=1216=EXPORT_SYMBOL_GPL(phy_pse_control_unlock);\n--\ndrivers/net/phy/phy_device.c-1225- */\ndrivers/net/phy/phy_device.c:1226:static int __phy_device_register(struct phy_device *phydev)\ndrivers/net/phy/phy_device.c-1227-{\n--\ndrivers/net/phy/phy_device.c=1267=int phy_device_register_locked(struct phy_device *phydev)\n--\ndrivers/net/phy/phy_device.c-1272-\ndrivers/net/phy/phy_device.c:1273:\terr = __phy_device_register(phydev);\ndrivers/net/phy/phy_device.c-1274-\tif (err)\n--\ndrivers/net/phy/phy_device.c=1291=int phy_device_register(struct phy_device *phydev)\n--\ndrivers/net/phy/phy_device.c-1294-\ndrivers/net/phy/phy_device.c:1295:\terr = __phy_device_register(phydev);\ndrivers/net/phy/phy_device.c-1296-\tif (err)\n"
}

gemini-3.1-pro-preview

null

null

							input: 20709
							output: 31
							thoughts: 497
						

**Analyzing the PSE Driver and Configuration**

Okay, so I'm looking at this code and trying to get a handle on what's going on with this PSE driver. The initial clue is that this code is likely directly called, and possibly inlined. Therefore, I need to focus my attention on specific symbols to understand its behavior and relationships. I need to keep an eye out for these: `phy_pse_control_lock`, `phy_pse_control_unlock`, `phy_device_register_locked`, `phy_device_register`, `phy_device_remove`, `pse_register_notifier`, `pse_unregister_notifier`, `pse_controller_register`, `pse_controller_unregister`, `pse_control_matches_pcdev`, `ethnl_set_pse`, `pse_prepare_data`, `phy_pse_attach_one`, and `phy_pse_detach_one`, `phy_pse_notifier_event`. These functions will paint the picture of how it all works.

Now, I need to verify which configurations are required for this driver to function. Let me see... I've got `CONFIG_PSE_CONTROLLER` and `CONFIG_REGULATOR` that are obviously needed. Wait, it seems like the `PSE_REGULATOR` is actually the driver. So I'll need `CONFIG_PSE_REGULATOR`... Ah yes, that's it. It's listed in `drivers/net/pse-pd/Kconfig`. I see `config PSE_REGULATOR` in there. Ok, so `PSE_REGULATOR` is the config name for the driver. Wait, `PSE_CONTROLLER` is a boolean, while `PSE_REGULATOR` is a tristate. Therefore, both `PSE_CONTROLLER`, `PSE_REGULATOR`, and `REGULATOR` configs should definitely go into `EnableConfigs`.

Next, I'll need to see if it's compiled. I'll check `net/ethtool/pse-pd.c`. The driver is compiled if `CONFIG_ETHTOOL_NETLINK` is enabled. That should be enabled by default, so I'm likely good there.

I'll also have to make sure the core PHY library is available. Looking at `drivers/net/phy/phy_device.c`, it's compiled if `CONFIG_PHYLIB` is enabled. That's usually enabled, so I'm probably fine.

Finally, the patch mentions changes to `sfp_sm_probe_phy` in `sfp.c`. Let me just double check if `sfp.c` is compiled. Ok, just making sure everything is ready.

{
  "Expression": "sfp.o",
  "PathPrefix": "drivers/net/phy/Makefile"
}

{
  "Output": "drivers/net/phy/Makefile=24=obj-$(CONFIG_NETWORK_PHY_TIMESTAMPING) += mii_timestamper.o\ndrivers/net/phy/Makefile-25-\ndrivers/net/phy/Makefile:26:obj-$(CONFIG_SFP)\t\t+= sfp.o\ndrivers/net/phy/Makefile:27:sfp-obj-$(CONFIG_SFP)\t\t+= sfp-bus.o\ndrivers/net/phy/Makefile:28:obj-y\t\t\t\t+= $(sfp-obj-y) $(sfp-obj-m)\ndrivers/net/phy/Makefile-29-\n"
}

gemini-3.1-pro-preview

null

null

							input: 21976
							output: 36
							thoughts: 71
						

Here's my take on those steps:

**Kernel Configuration Dependencies**

Okay, so I'm tracking a dependency here. I see that the `sfp.c` module absolutely needs `CONFIG_SFP` to compile. Makes perfect sense. Right, let's get that squared away. I'll add `SFP` to the `EnableConfigs` list. No reason to leave that hanging.

While I'm at it, I'll quickly double-check the configuration of this `drivers/net/mdio/fwnode_mdio.c` file. Ah, yes, it depends on `CONFIG_FWNODE_MDIO`, as expected. Good. It's always a good idea to confirm those dependencies and ensure I've got everything lined up in my head.

{
  "Expression": "fwnode_mdio.o",
  "PathPrefix": "drivers/net/mdio/Makefile"
}

{
  "Output": "drivers/net/mdio/Makefile=4=obj-$(CONFIG_ACPI_MDIO)\t\t+= acpi_mdio.o\ndrivers/net/mdio/Makefile:5:obj-$(CONFIG_FWNODE_MDIO)\t+= fwnode_mdio.o\ndrivers/net/mdio/Makefile-6-obj-$(CONFIG_OF_MDIO)\t\t+= of_mdio.o\n"
}

gemini-3.1-pro-preview

null

null

							input: 22360
							output: 31
							thoughts: 510
						

**Analyzing the PHY and PSE Controller Changes**

Okay, so I'm looking at this patch and thinking we need to add `FWNODE_MDIO` to `EnableConfigs`. Let's review the implications here; this is a pretty substantial change in how the PHY library and ethtool handle PSE controllers.

The patch is shifting the PSE control attachment. Instead of attaching it through `fwnode_mdiobus_register_phy`, it's now being handled in `phy_device_register` and, crucially, `phy_device_register_locked`. That's a key move. To serialize access to `phydev->psec` against the PSE notifier and ethtool, we're introducing a `phy_pse_lock` mutex. This is a very good idea to prevent race conditions. We're also introducing a `phy_pse_notifier` notifier which will attach and detach the PSE control as the PSE controller registers and unregisters.

The changes to `ethnl_set_pse` and `pse_prepare_data` to use `phy_pse_control_lock()` and `phy_pse_control_unlock()` are also smart. It's solidifying the locking to ensure data consistency. And finally, the modification to `sfp_sm_probe_phy` to use `phy_device_register_locked` instead of `phy_device_register` follows this change and uses proper locking in that function as well.

This is a significant functional shift. This is likely fixing a potential race condition or lifecycle issue with PSE controllers that we probably saw during testing. It definitely warrants a full fuzzing pass.

Now, I want to make sure I'm fully up to speed on all the symbols affected. Let me focus on: `phy_pse_control_lock`, `phy_pse_control_unlock`, `phy_device_register_locked`, `phy_device_register`, `phy_device_remove`, `pse_register_notifier`, `pse_unregister_notifier`, `pse_controller_register`, `pse_controller_unregister`, `pse_control_matches_pcdev`, `ethnl_set_pse`, `pse_prepare_data`, `phy_pse_attach_one`, `phy_pse_detach_one`, and `phy_pse_notifier_event`. These are all central to the logic here.

We need to confirm the correct enablement configs. We need `PSE_CONTROLLER`, `PSE_REGULATOR`, `REGULATOR`, `SFP`, and `FWNODE_MDIO`.

Let's double-check the `PSE_REGULATOR` config. Looking at `drivers/net/pse-pd/Kconfig`:
```
config PSE_REGULATOR
	tristate "Regulator based PSE controller"
```
Yes, `PSE_REGULATOR` is the right one, that's correct.

Let's also make sure `SFP` is enabled correctly. Checking `drivers/net/phy/Kconfig`: ...

{
  "Expression": "config SFP",
  "PathPrefix": "drivers/net/phy/Kconfig"
}

{
  "Output": "drivers/net/phy/Kconfig=65=config RUST_PHYLIB_ABSTRACTIONS\n--\ndrivers/net/phy/Kconfig-72-\ndrivers/net/phy/Kconfig:73:config SFP\ndrivers/net/phy/Kconfig-74-\ttristate \"SFP cage support\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 23638
							output: 35
							thoughts: 41
						

**Confirming the Configuration**

Alright, yes, I agree, `SFP` is definitely the correct option here. Now, I need to make absolutely sure about `FWNODE_MDIO`. Let's just double-check that configuration, shall we? I'll pop over to `drivers/net/mdio/Kconfig` to verify. I need to be certain before I move on.

{
  "Expression": "config FWNODE_MDIO",
  "PathPrefix": "drivers/net/mdio/Kconfig"
}

{
  "Output": "drivers/net/mdio/Kconfig=6=if PHYLIB\ndrivers/net/mdio/Kconfig-7-\ndrivers/net/mdio/Kconfig:8:config FWNODE_MDIO\ndrivers/net/mdio/Kconfig-9-\tdef_tristate (ACPI || OF) || COMPILE_TEST\n"
}

gemini-3.1-pro-preview

null

null

							input: 23889
							output: 31
							thoughts: 40
						

**Confirming the Configuration**

Alright, yes, `FWNODE_MDIO` feels right, that rings true. Now, just to be absolutely certain, before I proceed with any changes, let's quickly verify that `REGULATOR` is the appropriate configuration option we're looking at. Best practice, always. A quick look within `drivers/regulator/Kconfig` should provide the answer. I need that absolute clarity.

{
  "Expression": "config REGULATOR",
  "PathPrefix": "drivers/regulator/Kconfig"
}

{
  "Output": "\nFull output is too long, showing 500 out of 833 lines.\nUse more precise expression if possible.\n\ndrivers/regulator/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/regulator/Kconfig:2:menuconfig REGULATOR\ndrivers/regulator/Kconfig-3-\tbool \"Voltage and Current Regulator Support\"\n--\ndrivers/regulator/Kconfig=26=if REGULATOR\ndrivers/regulator/Kconfig-27-\ndrivers/regulator/Kconfig:28:config REGULATOR_DEBUG\ndrivers/regulator/Kconfig-29-\tbool \"Regulator debug support\"\n--\ndrivers/regulator/Kconfig-32-\ndrivers/regulator/Kconfig:33:config REGULATOR_FIXED_VOLTAGE\ndrivers/regulator/Kconfig-34-\ttristate \"Fixed voltage regulator support\"\n--\ndrivers/regulator/Kconfig-39-\ndrivers/regulator/Kconfig:40:config REGULATOR_VIRTUAL_CONSUMER\ndrivers/regulator/Kconfig-41-\ttristate \"Virtual regulator consumer support\"\n--\ndrivers/regulator/Kconfig-49-\ndrivers/regulator/Kconfig:50:config REGULATOR_USERSPACE_CONSUMER\ndrivers/regulator/Kconfig-51-\ttristate \"Userspace regulator consumer support\"\n--\ndrivers/regulator/Kconfig-58-\ndrivers/regulator/Kconfig:59:config REGULATOR_NETLINK_EVENTS\ndrivers/regulator/Kconfig-60-\tbool \"Enable support for receiving regulator events via netlink\"\n--\ndrivers/regulator/Kconfig-68-\ndrivers/regulator/Kconfig:69:config REGULATOR_88PG86X\ndrivers/regulator/Kconfig-70-\ttristate \"Marvell 88PG86X voltage regulators\"\n--\ndrivers/regulator/Kconfig-77-\ndrivers/regulator/Kconfig:78:config REGULATOR_88PM800\ndrivers/regulator/Kconfig-79-\ttristate \"Marvell 88PM800 Power regulators\"\n--\ndrivers/regulator/Kconfig-87-\ndrivers/regulator/Kconfig:88:config REGULATOR_88PM8607\ndrivers/regulator/Kconfig-89-\ttristate \"Marvell 88PM8607 Power regulators\"\n--\ndrivers/regulator/Kconfig-93-\ndrivers/regulator/Kconfig:94:config REGULATOR_88PM886\ndrivers/regulator/Kconfig-95-\ttristate \"Marvell 88PM886 voltage regulators\"\n--\ndrivers/regulator/Kconfig-99-\ndrivers/regulator/Kconfig:100:config REGULATOR_ACT8865\ndrivers/regulator/Kconfig-101-\ttristate \"Active-semi act8865 voltage regulator\"\n--\ndrivers/regulator/Kconfig-108-\ndrivers/regulator/Kconfig:109:config REGULATOR_ACT8945A\ndrivers/regulator/Kconfig-110-\ttristate \"Active-semi ACT8945A voltage regulator\"\n--\ndrivers/regulator/Kconfig-117-\ndrivers/regulator/Kconfig:118:config REGULATOR_AD5398\ndrivers/regulator/Kconfig-119-\ttristate \"Analog Devices AD5398/AD5821 regulators\"\n--\ndrivers/regulator/Kconfig-124-\ndrivers/regulator/Kconfig:125:config REGULATOR_ADP5055\ndrivers/regulator/Kconfig-126-\ttristate \"Analog Devices ADP5055 Triple Buck Regulator\"\n--\ndrivers/regulator/Kconfig-135-\ndrivers/regulator/Kconfig:136:config REGULATOR_ANATOP\ndrivers/regulator/Kconfig-137-\ttristate \"Freescale i.MX on-chip ANATOP LDO regulators\"\n--\ndrivers/regulator/Kconfig-144-\ndrivers/regulator/Kconfig:145:config REGULATOR_AAT2870\ndrivers/regulator/Kconfig-146-\ttristate \"AnalogicTech AAT2870 Regulators\"\n--\ndrivers/regulator/Kconfig-151-\ndrivers/regulator/Kconfig:152:config REGULATOR_AB8500\ndrivers/regulator/Kconfig-153-\tbool \"ST-Ericsson AB8500 Power Regulators\"\n--\ndrivers/regulator/Kconfig-158-\ndrivers/regulator/Kconfig:159:config REGULATOR_ARIZONA_LDO1\ndrivers/regulator/Kconfig-160-\ttristate \"Cirrus Madera and Wolfson Arizona class devices LDO1\"\n--\ndrivers/regulator/Kconfig-166-\ndrivers/regulator/Kconfig:167:config REGULATOR_ARIZONA_MICSUPP\ndrivers/regulator/Kconfig-168-\ttristate \"Cirrus Madera and Wolfson Arizona class devices MICSUPP\"\n--\ndrivers/regulator/Kconfig-175-\ndrivers/regulator/Kconfig:176:config REGULATOR_ARM_SCMI\ndrivers/regulator/Kconfig-177-\ttristate \"SCMI based regulator driver\"\n--\ndrivers/regulator/Kconfig-184-\ndrivers/regulator/Kconfig:185:config REGULATOR_AS3711\ndrivers/regulator/Kconfig-186-\ttristate \"AS3711 PMIC\"\n--\ndrivers/regulator/Kconfig-191-\ndrivers/regulator/Kconfig:192:config REGULATOR_AS3722\ndrivers/regulator/Kconfig-193-\ttristate \"AMS AS3722 PMIC Regulators\"\n--\ndrivers/regulator/Kconfig-199-\ndrivers/regulator/Kconfig:200:config REGULATOR_ATC260X\ndrivers/regulator/Kconfig-201-\ttristate \"Actions Semi ATC260x PMIC Regulators\"\n--\ndrivers/regulator/Kconfig-207-\ndrivers/regulator/Kconfig:208:config REGULATOR_AW37503\ndrivers/regulator/Kconfig-209-\ttristate \"Awinic AW37503 Dual Output Power regulators\"\n--\ndrivers/regulator/Kconfig-215-\ndrivers/regulator/Kconfig:216:config REGULATOR_AXP20X\ndrivers/regulator/Kconfig-217-\ttristate \"X-POWERS AXP20X PMIC Regulators\"\n--\ndrivers/regulator/Kconfig-222-\ndrivers/regulator/Kconfig:223:config REGULATOR_BCM590XX\ndrivers/regulator/Kconfig-224-\ttristate \"Broadcom BCM590xx PMU Regulators\"\n--\ndrivers/regulator/Kconfig-230-\ndrivers/regulator/Kconfig:231:config REGULATOR_BD71815\ndrivers/regulator/Kconfig-232-\ttristate \"ROHM BD71815 Power Regulator\"\n--\ndrivers/regulator/Kconfig-242-\ndrivers/regulator/Kconfig:243:config REGULATOR_BD71828\ndrivers/regulator/Kconfig-244-\ttristate \"ROHM BD71828, BD72720 and BD73900 Power Regulators\"\n--\ndrivers/regulator/Kconfig-254-\ndrivers/regulator/Kconfig:255:config REGULATOR_BD718XX\ndrivers/regulator/Kconfig-256-\ttristate \"ROHM BD71837 Power Regulator\"\n--\ndrivers/regulator/Kconfig-266-\ndrivers/regulator/Kconfig:267:config REGULATOR_BD9571MWV\ndrivers/regulator/Kconfig-268-\ttristate \"ROHM BD9571MWV Regulators\"\n--\ndrivers/regulator/Kconfig-277-\ndrivers/regulator/Kconfig:278:config REGULATOR_BD957XMUF\ndrivers/regulator/Kconfig-279-\ttristate \"ROHM BD9576MUF and BD9573MUF Regulators\"\n--\ndrivers/regulator/Kconfig-287-\ndrivers/regulator/Kconfig:288:config REGULATOR_BD96801\ndrivers/regulator/Kconfig-289-\ttristate \"ROHM BD96801 Power Regulator\"\n--\ndrivers/regulator/Kconfig-299-\ndrivers/regulator/Kconfig:300:config REGULATOR_BQ257XX\ndrivers/regulator/Kconfig-301-\ttristate \"TI BQ257XX regulator family\"\n--\ndrivers/regulator/Kconfig-307-\ndrivers/regulator/Kconfig:308:config REGULATOR_CPCAP\ndrivers/regulator/Kconfig-309-\ttristate \"Motorola CPCAP regulator\"\n--\ndrivers/regulator/Kconfig-314-\ndrivers/regulator/Kconfig:315:config REGULATOR_CROS_EC\ndrivers/regulator/Kconfig-316-\ttristate \"ChromeOS EC regulators\"\n--\ndrivers/regulator/Kconfig-324-\ndrivers/regulator/Kconfig:325:config REGULATOR_DA903X\ndrivers/regulator/Kconfig-326-\ttristate \"Dialog Semiconductor DA9030/DA9034 regulators\"\n--\ndrivers/regulator/Kconfig-332-\ndrivers/regulator/Kconfig:333:config REGULATOR_DA9052\ndrivers/regulator/Kconfig-334-\ttristate \"Dialog Semiconductor DA9052/DA9053 regulators\"\n--\ndrivers/regulator/Kconfig-339-\ndrivers/regulator/Kconfig:340:config REGULATOR_DA9055\ndrivers/regulator/Kconfig-341-\ttristate \"Dialog Semiconductor DA9055 regulators\"\n--\ndrivers/regulator/Kconfig-349-\ndrivers/regulator/Kconfig:350:config REGULATOR_DA9062\ndrivers/regulator/Kconfig-351-\ttristate \"Dialog Semiconductor DA9061/62 regulators\"\n--\ndrivers/regulator/Kconfig-359-\ndrivers/regulator/Kconfig:360:config REGULATOR_DA9063\ndrivers/regulator/Kconfig-361-\ttristate \"Dialog Semiconductor DA9063 regulators\"\n--\ndrivers/regulator/Kconfig-369-\ndrivers/regulator/Kconfig:370:config REGULATOR_DA9121\ndrivers/regulator/Kconfig-371-\ttristate \"Dialog Semiconductor DA9121/DA9122/DA9220/DA9217/DA9130/DA9131/DA9132 regulator\"\n--\ndrivers/regulator/Kconfig-389-\ndrivers/regulator/Kconfig:390:config REGULATOR_DA9210\ndrivers/regulator/Kconfig-391-\ttristate \"Dialog Semiconductor DA9210 regulator\"\n--\ndrivers/regulator/Kconfig-399-\ndrivers/regulator/Kconfig:400:config REGULATOR_DA9211\ndrivers/regulator/Kconfig-401-\ttristate \"Dialog Semiconductor DA9211/DA9212/DA9213/DA9223/DA9214/DA9224/DA9215/DA9225 regulator\"\n--\ndrivers/regulator/Kconfig-410-\ndrivers/regulator/Kconfig:411:config REGULATOR_DBX500_PRCMU\ndrivers/regulator/Kconfig-412-\tbool\ndrivers/regulator/Kconfig-413-\ndrivers/regulator/Kconfig:414:config REGULATOR_DB8500_PRCMU\ndrivers/regulator/Kconfig-415-\tbool \"ST-Ericsson DB8500 Voltage Domain Regulators\"\n--\ndrivers/regulator/Kconfig-421-\ndrivers/regulator/Kconfig:422:config REGULATOR_FAN53555\ndrivers/regulator/Kconfig-423-\ttristate \"Fairchild FAN53555 Regulator\"\n--\ndrivers/regulator/Kconfig-432-\ndrivers/regulator/Kconfig:433:config REGULATOR_FAN53880\ndrivers/regulator/Kconfig-434-\ttristate \"Fairchild FAN53880 Regulator\"\n--\ndrivers/regulator/Kconfig-442-\ndrivers/regulator/Kconfig:443:config REGULATOR_GPIO\ndrivers/regulator/Kconfig-444-\ttristate \"GPIO regulator support\"\n--\ndrivers/regulator/Kconfig-452-\ndrivers/regulator/Kconfig:453:config REGULATOR_HI6421\ndrivers/regulator/Kconfig-454-\ttristate \"HiSilicon Hi6421 PMIC voltage regulator support\"\n--\ndrivers/regulator/Kconfig-462-\ndrivers/regulator/Kconfig:463:config REGULATOR_HI6421V530\ndrivers/regulator/Kconfig-464-\ttristate \"HiSilicon Hi6421v530 PMIC voltage regulator support\"\n--\ndrivers/regulator/Kconfig-472-\ndrivers/regulator/Kconfig:473:config REGULATOR_HI655X\ndrivers/regulator/Kconfig-474-\ttristate \"Hisilicon HI655X PMIC regulators support\"\n--\ndrivers/regulator/Kconfig-480-\ndrivers/regulator/Kconfig:481:config REGULATOR_HI6421V600\ndrivers/regulator/Kconfig-482-\ttristate \"HiSilicon Hi6421v600 PMIC voltage regulator support\"\n--\ndrivers/regulator/Kconfig-489-\ndrivers/regulator/Kconfig:490:config REGULATOR_ISL9305\ndrivers/regulator/Kconfig-491-\ttristate \"Intersil ISL9305 regulator\"\n--\ndrivers/regulator/Kconfig-496-\ndrivers/regulator/Kconfig:497:config REGULATOR_ISL6271A\ndrivers/regulator/Kconfig-498-\ttristate \"Intersil ISL6271A Power regulator\"\n--\ndrivers/regulator/Kconfig-502-\ndrivers/regulator/Kconfig:503:config REGULATOR_FP9931\ndrivers/regulator/Kconfig-504-\ttristate \"FitiPower FP9931/JD9930 EPD regulator\"\n--\ndrivers/regulator/Kconfig-512-\ndrivers/regulator/Kconfig:513:config REGULATOR_LM363X\ndrivers/regulator/Kconfig-514-\ttristate \"TI LM363X voltage regulators\"\n--\ndrivers/regulator/Kconfig-521-\ndrivers/regulator/Kconfig:522:config REGULATOR_LOCHNAGAR\ndrivers/regulator/Kconfig-523-\ttristate \"Cirrus Logic Lochnagar regulator driver\"\n--\ndrivers/regulator/Kconfig-528-\ndrivers/regulator/Kconfig:529:config REGULATOR_LP3971\ndrivers/regulator/Kconfig-530-\ttristate \"National Semiconductors LP3971 PMIC regulator driver\"\n--\ndrivers/regulator/Kconfig-535-\ndrivers/regulator/Kconfig:536:config REGULATOR_LP3972\ndrivers/regulator/Kconfig-537-\ttristate \"National Semiconductors LP3972 PMIC regulator driver\"\n--\ndrivers/regulator/Kconfig-542-\ndrivers/regulator/Kconfig:543:config REGULATOR_LP872X\ndrivers/regulator/Kconfig-544-\ttristate \"TI/National Semiconductor LP8720/LP8725 voltage regulators\"\n--\ndrivers/regulator/Kconfig-549-\ndrivers/regulator/Kconfig:550:config REGULATOR_LP873X\ndrivers/regulator/Kconfig-551-\ttristate \"TI LP873X Power regulators\"\n--\ndrivers/regulator/Kconfig-558-\ndrivers/regulator/Kconfig:559:config REGULATOR_LP8755\ndrivers/regulator/Kconfig-560-\ttristate \"TI LP8755 High Performance PMU driver\"\n--\ndrivers/regulator/Kconfig-567-\ndrivers/regulator/Kconfig:568:config REGULATOR_LP87565\ndrivers/regulator/Kconfig-569-\ttristate \"TI LP87565 Power regulators\"\n--\ndrivers/regulator/Kconfig-575-\ndrivers/regulator/Kconfig:576:config REGULATOR_LP8788\ndrivers/regulator/Kconfig-577-\ttristate \"TI LP8788 Power Regulators\"\n--\ndrivers/regulator/Kconfig-581-\ndrivers/regulator/Kconfig:582:config REGULATOR_LTC3589\ndrivers/regulator/Kconfig-583-\ttristate \"LTC3589 8-output voltage regulator\"\n--\ndrivers/regulator/Kconfig-589-\ndrivers/regulator/Kconfig:590:config REGULATOR_LTC3676\ndrivers/regulator/Kconfig-591-\ttristate \"LTC3676 8-output voltage regulator\"\n--\ndrivers/regulator/Kconfig-597-\ndrivers/regulator/Kconfig:598:config REGULATOR_MAX14577\ndrivers/regulator/Kconfig-599-\ttristate \"Maxim 14577/77836 regulator\"\n--\ndrivers/regulator/Kconfig-605-\ndrivers/regulator/Kconfig:606:config REGULATOR_MAX1586\ndrivers/regulator/Kconfig-607-\ttristate \"Maxim 1586/1587 voltage regulator\"\n--\ndrivers/regulator/Kconfig-613-\ndrivers/regulator/Kconfig:614:config REGULATOR_MAX5970\ndrivers/regulator/Kconfig-615-\ttristate \"Maxim 5970/5978 power switch and monitor\"\n--\ndrivers/regulator/Kconfig-623-\ndrivers/regulator/Kconfig:624:config REGULATOR_MAX77503\ndrivers/regulator/Kconfig-625-\ttristate \"Analog Devices MAX77503 Regulator\"\n--\ndrivers/regulator/Kconfig-633-\ndrivers/regulator/Kconfig:634:config REGULATOR_MAX77541\ndrivers/regulator/Kconfig-635-\ttristate \"Analog Devices MAX77541/77540 Regulator\"\n--\ndrivers/regulator/Kconfig-644-\ndrivers/regulator/Kconfig:645:config REGULATOR_MAX77620\ndrivers/regulator/Kconfig-646-\ttristate \"Maxim 77620/MAX20024 voltage regulator\"\n--\ndrivers/regulator/Kconfig-653-\ndrivers/regulator/Kconfig:654:config REGULATOR_MAX77650\ndrivers/regulator/Kconfig-655-\ttristate \"Maxim MAX77650/77651 regulator support\"\n--\ndrivers/regulator/Kconfig-661-\ndrivers/regulator/Kconfig:662:config REGULATOR_MAX77675\ndrivers/regulator/Kconfig-663-\ttristate \"Maxim MAX77675 regulator driver\"\n--\ndrivers/regulator/Kconfig-670-\ndrivers/regulator/Kconfig:671:config REGULATOR_MAX77857\ndrivers/regulator/Kconfig-672-\ttristate \"ADI MAX77857/MAX77831 regulator support\"\n--\ndrivers/regulator/Kconfig-680-\ndrivers/regulator/Kconfig:681:config REGULATOR_MAX8649\ndrivers/regulator/Kconfig-682-\ttristate \"Maxim 8649 voltage regulator\"\n--\ndrivers/regulator/Kconfig-688-\ndrivers/regulator/Kconfig:689:config REGULATOR_MAX8660\ndrivers/regulator/Kconfig-690-\ttristate \"Maxim 8660/8661 voltage regulator\"\n--\ndrivers/regulator/Kconfig-695-\ndrivers/regulator/Kconfig:696:config REGULATOR_MAX8893\ndrivers/regulator/Kconfig-697-\ttristate \"Maxim 8893 voltage regulator\"\n--\ndrivers/regulator/Kconfig-703-\ndrivers/regulator/Kconfig:704:config REGULATOR_MAX8907\ndrivers/regulator/Kconfig-705-\ttristate \"Maxim 8907 voltage regulator\"\n--\ndrivers/regulator/Kconfig-711-\ndrivers/regulator/Kconfig:712:config REGULATOR_MAX8925\ndrivers/regulator/Kconfig-713-\ttristate \"Maxim MAX8925 Power Management IC\"\n--\ndrivers/regulator/Kconfig-717-\ndrivers/regulator/Kconfig:718:config REGULATOR_MAX8952\ndrivers/regulator/Kconfig-719-\ttristate \"Maxim MAX8952 Power Management IC\"\n--\ndrivers/regulator/Kconfig-725-\ndrivers/regulator/Kconfig:726:config REGULATOR_MAX8973\ndrivers/regulator/Kconfig-727-\ttristate \"Maxim MAX8973A voltage regulator\"\n--\ndrivers/regulator/Kconfig-736-\ndrivers/regulator/Kconfig:737:config REGULATOR_MAX8997\ndrivers/regulator/Kconfig-738-\ttristate \"Maxim 8997/8966 regulator\"\n--\ndrivers/regulator/Kconfig-745-\ndrivers/regulator/Kconfig:746:config REGULATOR_MAX8998\ndrivers/regulator/Kconfig-747-\ttristate \"Maxim 8998 voltage regulator\"\n--\ndrivers/regulator/Kconfig-753-\ndrivers/regulator/Kconfig:754:config REGULATOR_MAX20086\ndrivers/regulator/Kconfig-755-\ttristate \"Maxim MAX20086-MAX20089 Camera Power Protectors\"\n--\ndrivers/regulator/Kconfig-762-\ndrivers/regulator/Kconfig:763:config REGULATOR_MAX20411\ndrivers/regulator/Kconfig-764-\ttristate \"Maxim MAX20411 High-Efficiency Single Step-Down Converter\"\n--\ndrivers/regulator/Kconfig-770-\ndrivers/regulator/Kconfig:771:config REGULATOR_MAX77686\ndrivers/regulator/Kconfig-772-\ttristate \"Maxim 77686 regulator\"\n--\ndrivers/regulator/Kconfig-778-\ndrivers/regulator/Kconfig:779:config REGULATOR_MAX77693\ndrivers/regulator/Kconfig-780-\ttristate \"Maxim 77693/77843 regulator\"\n--\ndrivers/regulator/Kconfig-787-\ndrivers/regulator/Kconfig:788:config REGULATOR_MAX77802\ndrivers/regulator/Kconfig-789-\ttristate \"Maxim 77802 regulator\"\n--\ndrivers/regulator/Kconfig-796-\ndrivers/regulator/Kconfig:797:config REGULATOR_MAX77826\ndrivers/regulator/Kconfig-798-\ttristate \"Maxim 77826 regulator\"\n--\ndrivers/regulator/Kconfig-806-\ndrivers/regulator/Kconfig:807:config REGULATOR_MAX77838\ndrivers/regulator/Kconfig-808-\ttristate \"Maxim 77838 regulator\"\n--\ndrivers/regulator/Kconfig-815-\ndrivers/regulator/Kconfig:816:config REGULATOR_MC13XXX_CORE\ndrivers/regulator/Kconfig-817-\ttristate\ndrivers/regulator/Kconfig-818-\ndrivers/regulator/Kconfig:819:config REGULATOR_MC13783\ndrivers/regulator/Kconfig-820-\ttristate \"Freescale MC13783 regulator driver\"\n--\ndrivers/regulator/Kconfig-826-\ndrivers/regulator/Kconfig:827:config REGULATOR_MC13892\ndrivers/regulator/Kconfig-828-\ttristate \"Freescale MC13892 regulator driver\"\n--\ndrivers/regulator/Kconfig-834-\ndrivers/regulator/Kconfig:835:config REGULATOR_MCP16502\ndrivers/regulator/Kconfig-836-\ttristate \"Microchip MCP16502 PMIC\"\n--\ndrivers/regulator/Kconfig-844-\ndrivers/regulator/Kconfig:845:config REGULATOR_MP5416\ndrivers/regulator/Kconfig-846-\ttristate \"Monolithic MP5416 PMIC\"\n--\ndrivers/regulator/Kconfig-854-\ndrivers/regulator/Kconfig:855:config REGULATOR_MP8859\ndrivers/regulator/Kconfig-856-\ttristate \"MPS MP8859 regulator driver\"\n--\ndrivers/regulator/Kconfig-865-\ndrivers/regulator/Kconfig:866:config REGULATOR_MP886X\ndrivers/regulator/Kconfig-867-\ttristate \"MPS MP8869 regulator driver\"\n--\ndrivers/regulator/Kconfig-872-\ndrivers/regulator/Kconfig:873:config REGULATOR_MPQ7920\ndrivers/regulator/Kconfig-874-\ttristate \"Monolithic MPQ7920 PMIC\"\n--\ndrivers/regulator/Kconfig-882-\ndrivers/regulator/Kconfig:883:config REGULATOR_MT6311\ndrivers/regulator/Kconfig-884-\ttristate \"MediaTek MT6311 PMIC\"\n--\ndrivers/regulator/Kconfig-892-\ndrivers/regulator/Kconfig:893:config REGULATOR_MT6315\ndrivers/regulator/Kconfig-894-\ttristate \"MediaTek MT6315 PMIC\"\n--\ndrivers/regulator/Kconfig-902-\ndrivers/regulator/Kconfig:903:config REGULATOR_MT6316\ndrivers/regulator/Kconfig-904-\ttristate \"MT6316 SPMI PMIC regulator driver\"\n--\ndrivers/regulator/Kconfig-912-\ndrivers/regulator/Kconfig:913:config REGULATOR_MT6323\ndrivers/regulator/Kconfig-914-\ttristate \"MediaTek MT6323 PMIC\"\n--\ndrivers/regulator/Kconfig-921-\ndrivers/regulator/Kconfig:922:config REGULATOR_MT6331\ndrivers/regulator/Kconfig-923-\ttristate \"MediaTek MT6331 PMIC\"\n--\ndrivers/regulator/Kconfig-930-\ndrivers/regulator/Kconfig:931:config REGULATOR_MT6332\ndrivers/regulator/Kconfig-932-\ttristate \"MediaTek MT6332 PMIC\"\n--\ndrivers/regulator/Kconfig-939-\ndrivers/regulator/Kconfig:940:config REGULATOR_MT6357\ndrivers/regulator/Kconfig-941-\ttristate \"MediaTek MT6357 PMIC\"\n--\ndrivers/regulator/Kconfig-948-\ndrivers/regulator/Kconfig:949:config REGULATOR_MT6358\ndrivers/regulator/Kconfig-950-\ttristate \"MediaTek MT6358 PMIC\"\n--\ndrivers/regulator/Kconfig-957-\ndrivers/regulator/Kconfig:958:config REGULATOR_MT6359\ndrivers/regulator/Kconfig-959-\ttristate \"MediaTek MT6359 PMIC\"\n--\ndrivers/regulator/Kconfig-966-\ndrivers/regulator/Kconfig:967:config REGULATOR_MT6360\ndrivers/regulator/Kconfig-968-\ttristate \"MT6360 SubPMIC Regulator\"\n--\ndrivers/regulator/Kconfig-975-\ndrivers/regulator/Kconfig:976:config REGULATOR_MT6363\ndrivers/regulator/Kconfig-977-\ttristate \"MT6363 SPMI PMIC regulator driver\"\n--\ndrivers/regulator/Kconfig-986-\ndrivers/regulator/Kconfig:987:config REGULATOR_MT6370\ndrivers/regulator/Kconfig-988-\ttristate \"MT6370 SubPMIC Regulator\"\n--\ndrivers/regulator/Kconfig-994-\ndrivers/regulator/Kconfig:995:config REGULATOR_MT6380\ndrivers/regulator/Kconfig-996-\ttristate \"MediaTek MT6380 PMIC\"\n--\ndrivers/regulator/Kconfig-1003-\ndrivers/regulator/Kconfig:1004:config REGULATOR_MT6397\ndrivers/regulator/Kconfig-1005-\ttristate \"MediaTek MT6397 PMIC\"\n--\ndrivers/regulator/Kconfig-1012-\ndrivers/regulator/Kconfig:1013:config REGULATOR_MTK_DVFSRC\ndrivers/regulator/Kconfig-1014-\ttristate \"MediaTek DVFSRC regulator driver\"\n--\ndrivers/regulator/Kconfig-1022-\ndrivers/regulator/Kconfig:1023:config REGULATOR_PALMAS\ndrivers/regulator/Kconfig-1024-\ttristate \"TI Palmas PMIC Regulators\"\n--\ndrivers/regulator/Kconfig-1034-\ndrivers/regulator/Kconfig:1035:config REGULATOR_PBIAS\ndrivers/regulator/Kconfig-1036-\ttristate \"PBIAS OMAP regulator driver\"\n--\ndrivers/regulator/Kconfig-1043-\ndrivers/regulator/Kconfig:1044:config REGULATOR_PCA9450\ndrivers/regulator/Kconfig-1045-\ttristate \"NXP PCA9450A/PCA9450B/PCA9450C regulator driver\"\n--\ndrivers/regulator/Kconfig-1051-\ndrivers/regulator/Kconfig:1052:config REGULATOR_PF9453\ndrivers/regulator/Kconfig-1053-\ttristate \"NXP PF9453 regulator driver\"\n--\ndrivers/regulator/Kconfig-1058-\ndrivers/regulator/Kconfig:1059:config REGULATOR_PF0900\ndrivers/regulator/Kconfig-1060-\ttristate \"NXP PF0900/PF0901/PF09XX regulator driver\"\n--\ndrivers/regulator/Kconfig-1066-\ndrivers/regulator/Kconfig:1067:config REGULATOR_PF530X\ndrivers/regulator/Kconfig-1068-\ttristate \"NXP PF5300/PF5301/PF5302 regulator driver\"\n--\ndrivers/regulator/Kconfig-1078-\ndrivers/regulator/Kconfig:1079:config REGULATOR_PF8X00\ndrivers/regulator/Kconfig-1080-\ttristate \"NXP PF8100/PF8121A/PF8200 regulator driver\"\n--\ndrivers/regulator/Kconfig-1090-\ndrivers/regulator/Kconfig:1091:config REGULATOR_PFUZE100\ndrivers/regulator/Kconfig-1092-\ttristate \"Freescale PFUZE100/200/3000/3001 regulator driver\"\n--\ndrivers/regulator/Kconfig-1098-\ndrivers/regulator/Kconfig:1099:config REGULATOR_PV88060\ndrivers/regulator/Kconfig-1100-\ttristate \"Powerventure Semiconductor PV88060 regulator\"\n--\ndrivers/regulator/Kconfig-1106-\ndrivers/regulator/Kconfig:1107:config REGULATOR_PV88080\ndrivers/regulator/Kconfig-1108-\ttristate \"Powerventure Semiconductor PV88080 regulator\"\n--\ndrivers/regulator/Kconfig-1113-\ndrivers/regulator/Kconfig:1114:config REGULATOR_PV88090\ndrivers/regulator/Kconfig-1115-\ttristate \"Powerventure Semiconductor PV88090 regulator\"\n--\ndrivers/regulator/Kconfig-1121-\n\n"
}

gemini-3.1-pro-preview

null

null

							input: 32705
							output: 293
							thoughts: 314
						

**My Assessment of the Code Changes**

Okay, after reviewing this, my initial assessment is confirmed: `REGULATOR` is indeed the correct component to focus on here. The changes are centered around the PSE controller's interaction with the PHY device, introducing a new locking mechanism (`phy_pse_lock`) and a notifier (`phy_pse_notifier`) to manage PSE controller registration and unregistration. This impacts both the core PHY library and ethtool, and since netlink and PHY device registration paths are involved, the potential attack surface is definitely present in virtualized setups.

The key configurations to consider here are: `PSE_CONTROLLER`, `PSE_REGULATOR`, `REGULATOR`, `SFP`, and `FWNODE_MDIO`. These all seem to be relevant to the changes being introduced.

I went through the `FocusSymbols` to double-check my understanding and all of them - `phy_pse_control_lock`, `phy_pse_control_unlock`, `phy_device_register_locked`, `phy_device_register`, `phy_device_remove`, `pse_register_notifier`, `pse_unregister_notifier`, `pse_controller_register`, `pse_controller_unregister`, `pse_control_matches_pcdev`, `ethnl_set_pse`, `pse_prepare_data`, `phy_pse_attach_one`, `phy_pse_detach_one`, and `phy_pse_notifier_event` - all seem valid and directly related to the new locking and notification mechanisms.

Alright, I'm confident in this analysis. Time to finalize the results and move on.

{
  "EnableConfigs": [
    "PSE_CONTROLLER",
    "PSE_REGULATOR",
    "REGULATOR",
    "SFP",
    "FWNODE_MDIO"
  ],
  "FocusSymbols": [
    "phy_pse_control_lock",
    "phy_pse_control_unlock",
    "phy_device_register_locked",
    "phy_device_register",
    "phy_device_remove",
    "pse_register_notifier",
    "pse_unregister_notifier",
    "pse_controller_register",
    "pse_controller_unregister",
    "pse_control_matches_pcdev",
    "ethnl_set_pse",
    "pse_prepare_data",
    "phy_pse_attach_one",
    "phy_pse_detach_one",
    "phy_pse_notifier_event"
  ],
  "Reasoning": "The patch changes how the PSE controller is attached to the PHY device, introducing a new lock (`phy_pse_lock`) and a notifier (`phy_pse_notifier`) to handle PSE controller registration and unregistration. It also modifies the ethtool PSE netlink interface to use the new lock. These changes affect the core PHY library and ethtool, and are reachable via netlink and PHY device registration paths, which can be triggered in virtualized environments.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "PSE_CONTROLLER",
    "PSE_REGULATOR",
    "REGULATOR",
    "SFP",
    "FWNODE_MDIO"
  ],
  "FocusSymbols": [
    "phy_pse_control_lock",
    "phy_pse_control_unlock",
    "phy_device_register_locked",
    "phy_device_register",
    "phy_device_remove",
    "pse_register_notifier",
    "pse_unregister_notifier",
    "pse_controller_register",
    "pse_controller_unregister",
    "pse_control_matches_pcdev",
    "ethnl_set_pse",
    "pse_prepare_data",
    "phy_pse_attach_one",
    "phy_pse_detach_one",
    "phy_pse_notifier_event"
  ],
  "Reasoning": "The patch changes how the PSE controller is attached to the PHY device, introducing a new lock (`phy_pse_lock`) and a notifier (`phy_pse_notifier`) to handle PSE controller registration and unregistration. It also modifies the ethtool PSE netlink interface to use the new lock. These changes affect the core PHY library and ethtool, and are reachable via netlink and PHY device registration paths, which can be triggered in virtualized environments.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

best-expensive

null

{
  "KMSANReasoning": "The patch series refactors the lifecycle and synchronization of PSE (Power Sourcing Equipment) controllers attached to PHY devices. It introduces a notifier chain (`phy_pse_notifier`) and a mutex (`phy_pse_lock`) to safely attach and detach `phydev-\u003epsec` when PSE controllers are registered or unregistered, preventing race conditions and use-after-free bugs. It also wraps ethtool PSE operations with the new lock.\n\nThese changes primarily address object lifecycle management, locking, and synchronization. Any bugs introduced by these changes would likely manifest as use-after-free, NULL pointer dereferences, or deadlocks, which are effectively caught by standard KASAN and LOCKDEP. The patch does not introduce new data structures sent to user space, nor does it involve complex buffer allocations or modifications to data length calculations that could expose uninitialized memory. Therefore, a dedicated KMSAN fuzzing session is not justified.",
  "NeedsKMSAN": false
}

You are an expert Linux kernel security engineer specializing in kernel memory
error detectors (KASAN and KMSAN). Your job is to review the provided patch series and
determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer)
fuzzing session in addition to standard KASAN fuzzing.

CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN:
- Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable
  a comprehensive suite of debugging tools and sanitizers, including KASAN
  (out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP
  (locking bugs and deadlocks), UB-sanitizers, and memory corruption checks.
- KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap,
  or page allocations) and kernel-to-user memory info-leaks.

Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN,
LOCKDEP, OR OTHER STANDARD BUG DETECTORS.
A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY
set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks
that are detected ONLY by KMSAN.

Look holistically at the patch series and surrounding code. Even if no direct
uninitialized field accesses or new buffer allocations are added in the diff itself,
a patch may alter control flow, bounds checking, or data length calculations in ways
that change how the rest of the code operates on existing buffers (e.g. allowing
uninitialized stack/heap memory to be read, copied to user space, or used in control
flow). Do not hesitate to use your code access tools to inspect the surrounding code,
called functions, and callers.

Set NeedsKMSAN=true ONLY IF the patch introduces or modifies:
1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb
   attributes, ioctl output arguments, socket options, or BPF buffers) where fields
   or structure padding might not be fully initialized/zeroed.
2. Conditional logic or branching that depends on potentially uninitialized variables
   or struct fields.
3. Allocation or initialization of complex data structures where uninitialized fields
   could be read later in reachable code paths.
4. Bounds checks, lengths, or logic in a way that allows surrounding code to access
   uninitialized bytes of existing buffers.

Set NeedsKMSAN=false IF:
- The code changes primarily risk out-of-bounds access, array overflows, NULL pointer
  dereferences, locking deadlocks, or use-after-free bugs (these are already caught
  by KASAN, LOCKDEP, or standard bug detectors).
- All stack/heap structures touched or introduced by the patch are fully zeroed
  or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied.
- The patch does not introduce any risk of uninitialized memory usage or info-leaks.

Use your code access tools to inspect the surrounding code if necessary, then provide
detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch.
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 668d093b09ff0e42bb4ab399d14e2aa0007ba5cd
Author: syz-cluster <triage@syzkaller.com>
Date:   Wed Aug 26 22:10:39 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c
index ba70915182654..7bd979b59f496 100644
--- a/drivers/net/mdio/fwnode_mdio.c
+++ b/drivers/net/mdio/fwnode_mdio.c
@@ -11,33 +11,11 @@
 #include <linux/fwnode_mdio.h>
 #include <linux/of.h>
 #include <linux/phy.h>
-#include <linux/pse-pd/pse.h>
 
 MODULE_AUTHOR("Calvin Johnson <calvin.johnson@oss.nxp.com>");
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("FWNODE MDIO bus (Ethernet PHY) accessors");
 
-static struct pse_control *
-fwnode_find_pse_control(struct fwnode_handle *fwnode,
-			struct phy_device *phydev)
-{
-	struct pse_control *psec;
-	struct device_node *np;
-
-	if (!IS_ENABLED(CONFIG_PSE_CONTROLLER))
-		return NULL;
-
-	np = to_of_node(fwnode);
-	if (!np)
-		return NULL;
-
-	psec = of_pse_control_get(np, phydev);
-	if (PTR_ERR(psec) == -ENOENT)
-		return NULL;
-
-	return psec;
-}
-
 static struct mii_timestamper *
 fwnode_find_mii_timestamper(struct fwnode_handle *fwnode)
 {
@@ -118,7 +96,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 				struct fwnode_handle *child, u32 addr)
 {
 	struct mii_timestamper *mii_ts = NULL;
-	struct pse_control *psec = NULL;
 	struct phy_device *phy;
 	bool is_c45;
 	u32 phy_id;
@@ -159,14 +136,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 			goto clean_phy;
 	}
 
-	psec = fwnode_find_pse_control(child, phy);
-	if (IS_ERR(psec)) {
-		rc = PTR_ERR(psec);
-		goto unregister_phy;
-	}
-
-	phy->psec = psec;
-
 	/* phy->mii_ts may already be defined by the PHY driver. A
 	 * mii_timestamper probed via the device tree will still have
 	 * precedence.
@@ -176,9 +145,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 
 	return 0;
 
-unregister_phy:
-	if (is_acpi_node(child) || is_of_node(child))
-		phy_device_remove(phy);
 clean_phy:
 	phy_device_free(phy);
 clean_mii_ts:
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 0615228459ef4..dca1b45bbbd26 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1102,11 +1102,128 @@ struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45)
 }
 EXPORT_SYMBOL(get_phy_device);
 
+/* Serialises phydev->psec against the PSE notifier and ethtool, not rtnl. */
+static DEFINE_MUTEX(phy_pse_lock);
+
+/* Best-effort attach of phydev->psec from a DT `pses = <&...>` phandle.
+ * Caller must hold phy_pse_lock. A missing phandle (-ENOENT) or a
+ * not-yet-registered controller (-EPROBE_DEFER) is silent; the notifier
+ * retries the latter at PSE_REGISTERED time. Any other error means a broken
+ * binding and is warned about, but left non-fatal so the phy still registers.
+ */
+static void phy_try_attach_pse(struct phy_device *phydev)
+{
+	struct pse_control *psec;
+	struct device_node *np;
+
+	lockdep_assert_held(&phy_pse_lock);
+
+	np = phydev->mdio.dev.of_node;
+	if (!np)
+		return;
+
+	if (phydev->psec)
+		return;
+
+	psec = of_pse_control_get(np, phydev);
+	if (IS_ERR(psec)) {
+		if (PTR_ERR(psec) != -EPROBE_DEFER && PTR_ERR(psec) != -ENOENT)
+			phydev_warn(phydev, "failed to get PSE control: %pe\n",
+				    psec);
+		return;
+	}
+
+	phydev->psec = psec;
+}
+
+static int phy_pse_attach_one(struct device *dev, void *data __maybe_unused)
+{
+	lockdep_assert_held(&phy_pse_lock);
+
+	if (dev->type != &mdio_bus_phy_type)
+		return 0;
+
+	phy_try_attach_pse(to_phy_device(dev));
+	return 0;
+}
+
+static int phy_pse_detach_one(struct device *dev, void *data)
+{
+	struct pse_controller_dev *pcdev = data;
+	struct phy_device *phydev;
+	struct pse_control *psec;
+
+	lockdep_assert_held(&phy_pse_lock);
+
+	if (dev->type != &mdio_bus_phy_type)
+		return 0;
+
+	phydev = to_phy_device(dev);
+	psec = phydev->psec;
+	if (!psec || !pse_control_matches_pcdev(psec, pcdev))
+		return 0;
+
+	phydev->psec = NULL;
+	pse_control_put(psec);
+	return 0;
+}
+
+static int phy_pse_notifier_event(struct notifier_block *nb,
+				  unsigned long event, void *data)
+{
+	switch (event) {
+	case PSE_REGISTERED:
+		mutex_lock(&phy_pse_lock);
+		bus_for_each_dev(&mdio_bus_type, NULL, NULL,
+				 phy_pse_attach_one);
+		mutex_unlock(&phy_pse_lock);
+		return NOTIFY_OK;
+	case PSE_UNREGISTERED:
+		mutex_lock(&phy_pse_lock);
+		bus_for_each_dev(&mdio_bus_type, NULL, data,
+				 phy_pse_detach_one);
+		mutex_unlock(&phy_pse_lock);
+		return NOTIFY_OK;
+	default:
+		return NOTIFY_DONE;
+	}
+}
+
+static struct notifier_block phy_pse_notifier __read_mostly = {
+	.notifier_call = phy_pse_notifier_event,
+};
+
 /**
- * phy_device_register - Register the phy device on the MDIO bus
- * @phydev: phy_device structure to be added to the MDIO bus
+ * phy_pse_control_lock - hold phydev->psec stable against PSE controller teardown
+ *
+ * The PSE_UNREGISTERED notifier detaches phydev->psec and drops its last
+ * reference. Callers that dereference phydev->psec (the ethtool PSE paths) must
+ * hold this lock across the access so the detach cannot run underneath them.
  */
-int phy_device_register(struct phy_device *phydev)
+void phy_pse_control_lock(void)
+{
+	mutex_lock(&phy_pse_lock);
+}
+EXPORT_SYMBOL_GPL(phy_pse_control_lock);
+
+/**
+ * phy_pse_control_unlock - release the lock taken by phy_pse_control_lock()
+ */
+void phy_pse_control_unlock(void)
+{
+	mutex_unlock(&phy_pse_lock);
+}
+EXPORT_SYMBOL_GPL(phy_pse_control_unlock);
+
+/* Core registration: add the phy to the MDIO bus. Does not touch rtnl or
+ * PSE. phydev->psec is attached by the callers below, after device_add()
+ * has made the phy visible on mdio_bus_type, so that a concurrent PSE
+ * notifier walk and the attach can never leave the phy unattached. Keeping
+ * device_add() out of rtnl also avoids deadlocking when binding a phy that
+ * itself provides an SFP cage (phy_probe() -> phy_sfp_probe() ->
+ * sfp_bus_add_upstream() takes rtnl).
+ */
+static int __phy_device_register(struct phy_device *phydev)
 {
 	int err;
 
@@ -1135,10 +1252,56 @@ int phy_device_register(struct phy_device *phydev)
  out:
 	/* Assert the reset signal */
 	phy_device_reset(phydev, 1);
-
 	mdiobus_unregister_device(&phydev->mdio);
 	return err;
 }
+
+/**
+ * phy_device_register_locked - Register the phy device on the MDIO bus
+ * @phydev: phy_device structure to be added to the MDIO bus
+ *
+ * Same as phy_device_register() but caller must already hold rtnl_lock().
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int phy_device_register_locked(struct phy_device *phydev)
+{
+	int err;
+
+	ASSERT_RTNL();
+
+	err = __phy_device_register(phydev);
+	if (err)
+		return err;
+
+	mutex_lock(&phy_pse_lock);
+	phy_try_attach_pse(phydev);
+	mutex_unlock(&phy_pse_lock);
+
+	return 0;
+}
+EXPORT_SYMBOL(phy_device_register_locked);
+
+/**
+ * phy_device_register - Register the phy device on the MDIO bus
+ * @phydev: phy_device structure to be added to the MDIO bus
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int phy_device_register(struct phy_device *phydev)
+{
+	int err;
+
+	err = __phy_device_register(phydev);
+	if (err)
+		return err;
+
+	mutex_lock(&phy_pse_lock);
+	phy_try_attach_pse(phydev);
+	mutex_unlock(&phy_pse_lock);
+
+	return 0;
+}
 EXPORT_SYMBOL(phy_device_register);
 
 /**
@@ -1152,7 +1315,15 @@ EXPORT_SYMBOL(phy_device_register);
 void phy_device_remove(struct phy_device *phydev)
 {
 	unregister_mii_timestamper(phydev->mii_ts);
+
+	/* Detach synchronously, before the phy leaves the bus, so the put cannot
+	 * outlive the PSE controller (an off-bus but still-pinned phy is missed by
+	 * the PSE_UNREGISTERED walk). phy_pse_lock serialises against that walk.
+	 */
+	mutex_lock(&phy_pse_lock);
 	pse_control_put(phydev->psec);
+	phydev->psec = NULL;
+	mutex_unlock(&phy_pse_lock);
 
 	device_del(&phydev->mdio.dev);
 
@@ -3981,8 +4152,14 @@ static int __init phy_init(void)
 	if (rc)
 		goto err_c45;
 
+	rc = pse_register_notifier(&phy_pse_notifier);
+	if (rc)
+		goto err_genphy;
+
 	return 0;
 
+err_genphy:
+	phy_driver_unregister(&genphy_driver);
 err_c45:
 	phy_driver_unregister(&genphy_c45_driver);
 err_ethtool_phy_ops:
@@ -3999,6 +4176,7 @@ static int __init phy_init(void)
 
 static void __exit phy_exit(void)
 {
+	pse_unregister_notifier(&phy_pse_notifier);
 	phy_driver_unregister(&genphy_c45_driver);
 	phy_driver_unregister(&genphy_driver);
 	rtnl_lock();
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 03bfd8640db96..18868bdd64852 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -2083,7 +2083,7 @@ static int sfp_sm_probe_phy(struct sfp *sfp, int addr, bool is_c45)
 	/* Mark this PHY as being on a SFP module */
 	phy->is_on_sfp_module = true;
 
-	err = phy_device_register(phy);
+	err = phy_device_register_locked(phy);
 	if (err) {
 		phy_device_free(phy);
 		dev_err(sfp->dev, "phy_device_register failed: %pe\n",
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 69dbdbde9d71a..611540df43bb1 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -8,6 +8,7 @@
 #include <linux/device.h>
 #include <linux/ethtool.h>
 #include <linux/ethtool_netlink.h>
+#include <linux/notifier.h>
 #include <linux/of.h>
 #include <linux/phy.h>
 #include <linux/pse-pd/pse.h>
@@ -23,6 +24,39 @@ static LIST_HEAD(pse_controller_list);
 static DEFINE_XARRAY_ALLOC(pse_pw_d_map);
 static DEFINE_MUTEX(pse_pw_d_mutex);
 
+static BLOCKING_NOTIFIER_HEAD(pse_controller_notifier);
+
+/**
+ * pse_register_notifier - register a callback for PSE controller events
+ * @nb: notifier block to register
+ *
+ * See enum pse_controller_event for events fired and their subscriber
+ * contract. Callbacks run in process context; they may sleep, take
+ * rtnl, and call of_pse_control_get(). The chain fires synchronously,
+ * so a PSE controller driver's probe/unbind path must not hold any
+ * such lock when calling pse_controller_register() or
+ * pse_controller_unregister().
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+int pse_register_notifier(struct notifier_block *nb)
+{
+	return blocking_notifier_chain_register(&pse_controller_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(pse_register_notifier);
+
+/**
+ * pse_unregister_notifier - unregister a previously registered callback
+ * @nb: notifier block previously passed to pse_register_notifier()
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+int pse_unregister_notifier(struct notifier_block *nb)
+{
+	return blocking_notifier_chain_unregister(&pse_controller_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(pse_unregister_notifier);
+
 /**
  * struct pse_control - a PSE control
  * @pcdev: a pointer to the PSE controller device
@@ -1104,6 +1138,9 @@ int pse_controller_register(struct pse_controller_dev *pcdev)
 	list_add(&pcdev->list, &pse_controller_list);
 	mutex_unlock(&pse_list_mutex);
 
+	blocking_notifier_call_chain(&pse_controller_notifier,
+				     PSE_REGISTERED, pcdev);
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(pse_controller_register);
@@ -1114,6 +1151,9 @@ EXPORT_SYMBOL_GPL(pse_controller_register);
  */
 void pse_controller_unregister(struct pse_controller_dev *pcdev)
 {
+	blocking_notifier_call_chain(&pse_controller_notifier,
+				     PSE_UNREGISTERED, pcdev);
+
 	pse_flush_pw_ds(pcdev);
 	pse_release_pis(pcdev);
 	if (pcdev->irq)
@@ -1981,3 +2021,17 @@ bool pse_has_c33(struct pse_control *psec)
 	return psec->pcdev->types & ETHTOOL_PSE_C33;
 }
 EXPORT_SYMBOL_GPL(pse_has_c33);
+
+/**
+ * pse_control_matches_pcdev - Test whether a pse_control targets a controller
+ * @psec: pse_control obtained from of_pse_control_get()
+ * @pcdev: PSE controller to compare against
+ *
+ * Return: %true if @psec was obtained from @pcdev, %false otherwise.
+ */
+bool pse_control_matches_pcdev(struct pse_control *psec,
+			       struct pse_controller_dev *pcdev)
+{
+	return psec->pcdev == pcdev;
+}
+EXPORT_SYMBOL_GPL(pse_control_matches_pcdev);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 199a7aaa341bf..55a0049c6c2b5 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -2158,8 +2158,12 @@ struct phy_device *fwnode_phy_find_device(struct fwnode_handle *phy_fwnode);
 struct fwnode_handle *fwnode_get_phy_node(const struct fwnode_handle *fwnode);
 struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
 int phy_device_register(struct phy_device *phy);
+/* Caller must hold rtnl_lock(); see phy_device_register() for the public form. */
+int phy_device_register_locked(struct phy_device *phy);
 void phy_device_free(struct phy_device *phydev);
 void phy_device_remove(struct phy_device *phydev);
+void phy_pse_control_lock(void);
+void phy_pse_control_unlock(void);
 int phy_get_c45_ids(struct phy_device *phydev);
 int phy_init_hw(struct phy_device *phydev);
 int phy_suspend(struct phy_device *phydev);
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index 4e5696cfade7c..d4310ca71a3e0 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -21,6 +21,7 @@ struct net_device;
 struct phy_device;
 struct pse_controller_dev;
 struct netlink_ext_ack;
+struct notifier_block;
 
 /* C33 PSE extended state and substate. */
 struct ethtool_c33_pse_ext_state_info {
@@ -337,6 +338,24 @@ enum pse_budget_eval_strategies {
 	PSE_BUDGET_EVAL_STRAT_DYNAMIC	= 1 << 2,
 };
 
+/**
+ * enum pse_controller_event - PSE controller lifecycle events
+ *
+ * Event data in callbacks is always a pointer to the struct
+ * pse_controller_dev firing the event.
+ *
+ * @PSE_REGISTERED: controller added to pse_controller_list and
+ *	resolvable by of_pse_control_get().
+ * @PSE_UNREGISTERED: controller about to be removed from
+ *	pse_controller_list. Subscribers holding pse_control references
+ *	targeting it must drop them before returning and must not
+ *	acquire new references for it.
+ */
+enum pse_controller_event {
+	PSE_REGISTERED,
+	PSE_UNREGISTERED,
+};
+
 #if IS_ENABLED(CONFIG_PSE_CONTROLLER)
 int pse_controller_register(struct pse_controller_dev *pcdev);
 void pse_controller_unregister(struct pse_controller_dev *pcdev);
@@ -366,6 +385,12 @@ int pse_ethtool_set_prio(struct pse_control *psec,
 bool pse_has_podl(struct pse_control *psec);
 bool pse_has_c33(struct pse_control *psec);
 
+bool pse_control_matches_pcdev(struct pse_control *psec,
+			       struct pse_controller_dev *pcdev);
+
+int pse_register_notifier(struct notifier_block *nb);
+int pse_unregister_notifier(struct notifier_block *nb);
+
 #else
 
 static inline struct pse_control *of_pse_control_get(struct device_node *node,
@@ -416,6 +441,22 @@ static inline bool pse_has_c33(struct pse_control *psec)
 	return false;
 }
 
+static inline bool pse_control_matches_pcdev(struct pse_control *psec,
+					     struct pse_controller_dev *pcdev)
+{
+	return false;
+}
+
+static inline int pse_register_notifier(struct notifier_block *nb)
+{
+	return 0;
+}
+
+static inline int pse_unregister_notifier(struct notifier_block *nb)
+{
+	return 0;
+}
+
 #endif
 
 #endif
diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
index 757c9e0cc856f..4edd9a514de14 100644
--- a/net/ethtool/pse-pd.c
+++ b/net/ethtool/pse-pd.c
@@ -71,7 +71,9 @@ static int pse_prepare_data(const struct ethnl_req_info *req_base,
 	if (ret < 0)
 		return ret;
 
+	phy_pse_control_lock();
 	ret = pse_get_pse_attributes(phydev, info->extack, data);
+	phy_pse_control_unlock();
 
 	ethnl_ops_complete(dev);
 
@@ -281,9 +283,12 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 
 	phydev = ethnl_req_get_phydev(req_info, tb, ETHTOOL_A_PSE_HEADER,
 				      info->extack);
+
+	phy_pse_control_lock();
+
 	ret = ethnl_set_pse_validate(phydev, info);
 	if (ret)
-		return ret;
+		goto out;
 
 	if (tb[ETHTOOL_A_PSE_PRIO]) {
 		unsigned int prio;
@@ -291,7 +296,7 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 		prio = nla_get_u32(tb[ETHTOOL_A_PSE_PRIO]);
 		ret = pse_ethtool_set_prio(phydev->psec, info->extack, prio);
 		if (ret)
-			return ret;
+			goto out;
 	}
 
 	if (tb[ETHTOOL_A_C33_PSE_AVAIL_PW_LIMIT]) {
@@ -301,7 +306,7 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 		ret = pse_ethtool_set_pw_limit(phydev->psec, info->extack,
 					       pw_limit);
 		if (ret)
-			return ret;
+			goto out;
 	}
 
 	/* These values are already validated by the ethnl_pse_set_policy */
@@ -319,11 +324,11 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 		 */
 		ret = pse_ethtool_set_config(phydev->psec, info->extack,
 					     &config);
-		if (ret)
-			return ret;
 	}
 
+out:
 	/* Return errno or zero - PSE has no notification */
+	phy_pse_control_unlock();
 	return ret;
 }
 

gemini-3.1-pro-preview

null

null

							input: 8372
							output: 213
							thoughts: 869
						

**Analyzing the PSE Controller Integration Patch Series**

Okay, so this patch series is all about refining the interaction between Power Sourcing Equipment (PSE) controllers and PHY devices within the Linux kernel. It's fundamentally changing how `phydev->psec` is managed, shifting from direct attachment/detachment during PHY registration/unregistration to a notifier-based system. This sounds like a good move for improved robustness and flexibility.

My initial thought is to immediately check for potential uninitialized memory problems. The changes involve attaching/detaching the `psec`, which is a pointer. It introduces a `phy_pse_notifier` for attachment/detachment and adds `phy_pse_lock` to serialize access to `phydev->psec`, protecting against races between the notifier and `ethtool` operations. Also, `ethnl_set_pse` and `pse_prepare_data` are modified to use `phy_pse_control_lock()` when interacting with `phydev->psec`.

I need to confirm if these changes expose any new uninitialized memory vulnerabilities. The changes primarily revolve around synchronization and the object lifecycle of `phydev->psec`. They don't introduce new structures sent to userspace or complex data structures with uninitialized fields. The primary goal is to prevent use-after-free or NULL pointer dereferences by ensuring proper locking and lifecycle management. These types of issues are usually caught by KASAN and LOCKDEP.

Let's dig deeper into `pse_prepare_data`. It locks, then calls `pse_get_pse_attributes`. The critical thing is whether the new lock affects how `data` is initialized, but no, it just wraps a lock around it. In `ethnl_set_pse` it's the same, it just adds a lock.

So the patch adds `phy_pse_control_lock()` and `phy_pse_control_unlock()` which are wrappers around `mutex_lock(&phy_pse_lock)` and `mutex_unlock(&phy_pse_lock)`. The patch introduces `pse_register_notifier` and `pse_unregister_notifier`. No, this seems perfectly safe. This is all about object lifecycle and making sure there are no races.

Ultimately, these changes appear to be specifically addressing a potential use-after-free or race condition. If a PSE controller unregisters while a PHY is still referencing it. KASAN is the right tool for these, not KMSAN.

I'll double check the `phy_try_attach_pse` function as a final sanity check, but I'm not seeing anything that would result in an uninitialized memory condition there.

Given the nature of these changes, I'm confident there are no KMSAN concerns. The patch's focus is on lifecycle and synchronization, not uninitialized memory. Therefore, NeedsKMSAN should be set to `false`.

{
  "KMSANReasoning": "The patch series refactors the lifecycle and synchronization of PSE (Power Sourcing Equipment) controllers attached to PHY devices. It introduces a notifier chain (`phy_pse_notifier`) and a mutex (`phy_pse_lock`) to safely attach and detach `phydev-\u003epsec` when PSE controllers are registered or unregistered, preventing race conditions and use-after-free bugs. It also wraps ethtool PSE operations with the new lock.\n\nThese changes primarily address object lifecycle management, locking, and synchronization. Any bugs introduced by these changes would likely manifest as use-after-free, NULL pointer dereferences, or deadlocks, which are effectively caught by standard KASAN and LOCKDEP. The patch does not introduce new data structures sent to user space, nor does it involve complex buffer allocations or modifications to data length calculations that could expose uninitialized memory. Therefore, a dedicated KMSAN fuzzing session is not justified.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch series refactors the lifecycle and synchronization of PSE (Power Sourcing Equipment) controllers attached to PHY devices. It introduces a notifier chain (`phy_pse_notifier`) and a mutex (`phy_pse_lock`) to safely attach and detach `phydev-\u003epsec` when PSE controllers are registered or unregistered, preventing race conditions and use-after-free bugs. It also wraps ethtool PSE operations with the new lock.\n\nThese changes primarily address object lifecycle management, locking, and synchronization. Any bugs introduced by these changes would likely manifest as use-after-free, NULL pointer dereferences, or deadlocks, which are effectively caught by standard KASAN and LOCKDEP. The patch does not introduce new data structures sent to user space, nor does it involve complex buffer allocations or modifications to data length calculations that could expose uninitialized memory. Therefore, a dedicated KMSAN fuzzing session is not justified.",
  "NeedsKMSAN": false
}