[PATCH v5 0/3] Add reset deassertion for Aspeed MDIO

Dylan Hung posted 3 patches 4 years ago
There is a newer version of this series
.../bindings/net/aspeed,ast2600-mdio.yaml         |  6 ++++++
arch/arm/boot/dts/aspeed-g6.dtsi                  |  4 ++++
drivers/net/mdio/mdio-aspeed.c                    | 15 ++++++++++++++-
3 files changed, 24 insertions(+), 1 deletion(-)
[PATCH v5 0/3] Add reset deassertion for Aspeed MDIO
Posted by Dylan Hung 4 years ago
Add missing reset deassertion for Aspeed MDIO bus controller. The reset
is asserted by the hardware when power-on so the driver only needs to
deassert it. To be able to work with the old DT blobs, the reset is
optional since it may be deasserted by the bootloader or the previous
kernel.

V5:
- fix error of dt_binding_check

V4:
- use ASPEED_RESET_MII instead of hardcoding in dt-binding example

V3:
- remove reset property from the required list of the device tree
  bindings
- remove "Cc: stable@vger.kernel.org" from the commit messages
- add more description in the commit message of the dt-binding

V2:
- add reset property in the device tree bindings
- add reset assertion in the error path and driver remove

Dylan Hung (3):
  dt-bindings: net: add reset property for aspeed, ast2600-mdio binding
  net: mdio: add reset control for Aspeed MDIO
  ARM: dts: aspeed: add reset properties into MDIO nodes

 .../bindings/net/aspeed,ast2600-mdio.yaml         |  6 ++++++
 arch/arm/boot/dts/aspeed-g6.dtsi                  |  4 ++++
 drivers/net/mdio/mdio-aspeed.c                    | 15 ++++++++++++++-
 3 files changed, 24 insertions(+), 1 deletion(-)

-- 
2.25.1
Re: [PATCH v5 0/3] Add reset deassertion for Aspeed MDIO
Posted by Jakub Kicinski 4 years ago
On Wed, 13 Apr 2022 20:10:34 +0800 Dylan Hung wrote:
> Add missing reset deassertion for Aspeed MDIO bus controller. The reset
> is asserted by the hardware when power-on so the driver only needs to
> deassert it. To be able to work with the old DT blobs, the reset is
> optional since it may be deasserted by the bootloader or the previous
> kernel.

I presume you want this applied to net-next, but it appears there 
is a conflict or something. Could you resend the patches based on
net-next/master?