| Message ID | 20240225-realtek-reset-v5-0-5a4dc0879dfb@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | net: dsa: realtek: support reset controller and update docs | expand |
Hello: This series was applied to netdev/net-next.git (main) by David S. Miller <davem@davemloft.net>: On Sun, 25 Feb 2024 13:29:52 -0300 you wrote: > The driver previously supported reset pins using GPIO, but it lacked > support for reset controllers. Although a reset method is generally not > required, the driver fails to detect the switch if the reset was kept > asserted by a previous driver. > > This series adds support to reset a Realtek switch using a reset > controller. It also updates the binding documentation to remove the > requirement of a reset method and to add the new reset controller > property. > > [...] Here is the summary with links: - [net-next,v5,1/3] dt-bindings: net: dsa: realtek: reset-gpios is not required https://git.kernel.org/netdev/net-next/c/28001bb1955f - [net-next,v5,2/3] dt-bindings: net: dsa: realtek: add reset controller https://git.kernel.org/netdev/net-next/c/5fc2d68fc818 - [net-next,v5,3/3] net: dsa: realtek: support reset controller https://git.kernel.org/netdev/net-next/c/56998aa6b7f0 You are awesome, thank you!
The driver previously supported reset pins using GPIO, but it lacked support for reset controllers. Although a reset method is generally not required, the driver fails to detect the switch if the reset was kept asserted by a previous driver. This series adds support to reset a Realtek switch using a reset controller. It also updates the binding documentation to remove the requirement of a reset method and to add the new reset controller property. It was tested on a TL-WR1043ND v1 router (rtl8366rb via SMI). Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> --- Changes in v5: - Fixed error checking logic when reset controller (de)assert fails - Link to v4: https://lore.kernel.org/r/20240219-realtek-reset-v4-0-858b82a29503@gmail.com Changes in v4: - do not test for priv->reset,priv->reset_ctl - updated commit message - Link to v3: https://lore.kernel.org/r/20240213-realtek-reset-v3-0-37837e574713@gmail.com Changes in v3: - Rebased on the Realtek DSA driver refactoring (08f627164126) - Dropped the reset controller example in bindings - Used %pe in error printing - Linked to v2: https://lore.kernel.org/r/20231027190910.27044-1-luizluca@gmail.com/ Changes in v2: - Introduced a dedicated commit for removing the reset-gpios requirement - Placed binding patches before code changes - Removed the 'reset-names' property - Moved the example from the commit message to realtek.yaml - Split the reset function into _assert/_deassert variants - Modified reset functions to return a warning instead of a value - Utilized devm_reset_control_get_optional to prevent failure when the reset control is missing - Used 'true' and 'false' for boolean values - Removed the CONFIG_RESET_CONTROLLER check as stub methods are sufficient when undefined - Linked to v1: https://lore.kernel.org/r/20231024205805.19314-1-luizluca@gmail.com/ --- Luiz Angelo Daros de Luca (3): dt-bindings: net: dsa: realtek: reset-gpios is not required dt-bindings: net: dsa: realtek: add reset controller net: dsa: realtek: support reset controller .../devicetree/bindings/net/dsa/realtek.yaml | 4 ++- drivers/net/dsa/realtek/realtek.h | 2 ++ drivers/net/dsa/realtek/rtl83xx.c | 42 +++++++++++++++++++--- drivers/net/dsa/realtek/rtl83xx.h | 2 ++ 4 files changed, 44 insertions(+), 6 deletions(-) --- base-commit: d1d77120bc2867b3e449e07ee656a26b2fb03d1e change-id: 20240212-realtek-reset-88a0bf25bb22 Best regards,