| Message ID | 20220428114049.1456382-2-michael@walle.cc (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 4fdabd509df3fb5e731031197034cb02f053731a |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: lan966x: remove PHY reset support | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/fixes_present | success | Fixes tag not required for -next series |
| netdev/subject_prefix | success | Link |
| netdev/cover_letter | success | Series has a cover letter |
| netdev/patch_count | success | Link |
| netdev/header_inline | success | No static functions without inline keyword in header files |
| netdev/build_32bit | success | Errors and warnings before: 0 this patch: 0 |
| netdev/cc_maintainers | success | CCed 8 of 8 maintainers |
| netdev/build_clang | success | Errors and warnings before: 0 this patch: 0 |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Signed-off-by tag matches author and committer |
| netdev/verify_fixes | success | No Fixes tag |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
| netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 12 lines checked |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/source_inline | success | Was 0 now: 0 |
On Thu, Apr 28, 2022 at 6:40 AM Michael Walle <michael@walle.cc> wrote: > > The PHY reset was intended to be a phandle for a special PHY reset > driver for the integrated PHYs as well as any external PHYs. It turns > out, that the culprit is how the reset of the switch device is done. > In particular, the switch reset also affects other subsystems like > the GPIO and the SGPIO block and it happens to be the case that the > reset lines of the external PHYs are connected to a common GPIO line. > Thus as soon as the switch issues a reset during probe time, all the > external PHYs will go into reset because all the GPIO lines will > switch to input and the pull-down on that signal will take effect. > > So even if there was a special PHY reset driver, it (1) won't fix > the root cause of the problem and (2) it won't fix all the other > consumers of GPIO lines which will also be reset. > > It turns out, the Ocelot SoC has the same weird behavior (or the > lack of a dedicated switch reset) and there the problem is already > solved and all the bits and pieces are already there and this PHY > reset property isn't not needed at all. > > There are no users of this binding. Just remove it. Seems there was 1 user: /builds/robherring/linux-dt/Documentation/devicetree/bindings/net/microchip,lan966x-switch.example.dtb: switch@e0000000: resets: [[4294967295, 0], [4294967295, 0]] is too long From schema: /builds/robherring/linux-dt/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml /builds/robherring/linux-dt/Documentation/devicetree/bindings/net/microchip,lan966x-switch.example.dtb: switch@e0000000: reset-names: ['switch', 'phy'] is too long From schema: /builds/robherring/linux-dt/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml Please fix as this is now failing in linux-next. Rob
Am 2022-05-03 15:04, schrieb Rob Herring: > On Thu, Apr 28, 2022 at 6:40 AM Michael Walle <michael@walle.cc> wrote: >> >> The PHY reset was intended to be a phandle for a special PHY reset >> driver for the integrated PHYs as well as any external PHYs. It turns >> out, that the culprit is how the reset of the switch device is done. >> In particular, the switch reset also affects other subsystems like >> the GPIO and the SGPIO block and it happens to be the case that the >> reset lines of the external PHYs are connected to a common GPIO line. >> Thus as soon as the switch issues a reset during probe time, all the >> external PHYs will go into reset because all the GPIO lines will >> switch to input and the pull-down on that signal will take effect. >> >> So even if there was a special PHY reset driver, it (1) won't fix >> the root cause of the problem and (2) it won't fix all the other >> consumers of GPIO lines which will also be reset. >> >> It turns out, the Ocelot SoC has the same weird behavior (or the >> lack of a dedicated switch reset) and there the problem is already >> solved and all the bits and pieces are already there and this PHY >> reset property isn't not needed at all. >> >> There are no users of this binding. Just remove it. > > Seems there was 1 user: > > /builds/robherring/linux-dt/Documentation/devicetree/bindings/net/microchip,lan966x-switch.example.dtb: > switch@e0000000: resets: [[4294967295, 0], [4294967295, 0]] is too > long > From schema: > /builds/robherring/linux-dt/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml > /builds/robherring/linux-dt/Documentation/devicetree/bindings/net/microchip,lan966x-switch.example.dtb: > switch@e0000000: reset-names: ['switch', 'phy'] is too long > From schema: > /builds/robherring/linux-dt/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml > > Please fix as this is now failing in linux-next. Sorry. Should be fixed with https://lore.kernel.org/netdev/20220503132038.2714128-1-michael@walle.cc/ -michael
diff --git a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml index 131dc5a652de..f3ed708de0eb 100644 --- a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml +++ b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml @@ -53,12 +53,10 @@ properties: resets: items: - description: Reset controller used for switch core reset (soft reset) - - description: Reset controller used for releasing the phy from reset reset-names: items: - const: switch - - const: phy ethernet-ports: type: object
The PHY reset was intended to be a phandle for a special PHY reset driver for the integrated PHYs as well as any external PHYs. It turns out, that the culprit is how the reset of the switch device is done. In particular, the switch reset also affects other subsystems like the GPIO and the SGPIO block and it happens to be the case that the reset lines of the external PHYs are connected to a common GPIO line. Thus as soon as the switch issues a reset during probe time, all the external PHYs will go into reset because all the GPIO lines will switch to input and the pull-down on that signal will take effect. So even if there was a special PHY reset driver, it (1) won't fix the root cause of the problem and (2) it won't fix all the other consumers of GPIO lines which will also be reset. It turns out, the Ocelot SoC has the same weird behavior (or the lack of a dedicated switch reset) and there the problem is already solved and all the bits and pieces are already there and this PHY reset property isn't not needed at all. There are no users of this binding. Just remove it. Signed-off-by: Michael Walle <michael@walle.cc> --- .../devicetree/bindings/net/microchip,lan966x-switch.yaml | 2 -- 1 file changed, 2 deletions(-)