This MDIO hardware is based on a Microsemi design supported in Linux by
mdio-mscc-miim.c. However, The register interface is completely different
with pic64hpsc, hence the need for separate documentation.
The hardware supports C22 and C45.
The documentation recommends an input clock of 156.25MHz and a prescaler
of 39, which yields an MDIO clock of 1.95MHz.
The hardware supports an interrupt pin to signal transaction completion
which is not strictly needed as the software can also poll a "TRIGGER"
bit for this.
Signed-off-by: Charles Perry <charles.perry@microchip.com>
---
.../net/microchip,pic64hpsc-mdio.yaml | 61 +++++++++++++++++++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
diff --git a/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
new file mode 100644
index 000000000000..21c76199c11b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/microchip,pic64hpsc-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC64-HPSC/HX MDIO controller
+
+maintainers:
+ - Charles Perry <charles.perry@microchip.com>
+
+description: |
+ Microchip PIC64-HPSC/HX SoCs have two MDIO bus controller. This MDIO bus
+ controller supports C22 and C45 register access. It is named "MDIO Initiator"
+ in the documentation.
+
+allOf:
+ - $ref: mdio.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: microchip,pic64hpsc-mdio
+ - items:
+ - const: microchip,pic64hx-mdio
+ - const: microchip,pic64hpsc-mdio
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency: true
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ mdio@4000C21E000 {
+ compatible = "microchip,pic64hpsc-mdio";
+ reg = <0x400 0x0C21E000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+ };
--
2.47.3> The hardware supports an interrupt pin to signal transaction completion
> which is not strictly needed as the software can also poll a "TRIGGER"
> bit for this.
If the interrupt always exists, it is better to have it in DT. I
assume it will be in the SoC .dtsi file?
Always requiring it makes the code simpler when somebody adds support
for interrupts. You don't need all the _optional_ and dealing with it
being missing etc.
Andrew
On Thu, Mar 19, 2026 at 05:59:36PM +0100, Andrew Lunn wrote: > > The hardware supports an interrupt pin to signal transaction completion > > which is not strictly needed as the software can also poll a "TRIGGER" > > bit for this. > > If the interrupt always exists, it is better to have it in DT. I > assume it will be in the SoC .dtsi file? > Yes, I have that interrupt in my .dtsi. > Always requiring it makes the code simpler when somebody adds support > for interrupts. You don't need all the _optional_ and dealing with it > being missing etc. > Good point, I'll add that to the required properties. Thanks, Charles
> The hardware supports an interrupt pin to signal transaction completion
> which is not strictly needed as the software can also poll a "TRIGGER"
> bit for this.
Experience with the FEC is that using interrupts is slower, but you
save some CPU load. The vast majority of MDIO devices poll.
Andrew
On Tue, Mar 17, 2026 at 11:46:09AM -0700, Charles Perry wrote:
> This MDIO hardware is based on a Microsemi design supported in Linux by
> mdio-mscc-miim.c. However, The register interface is completely different
> with pic64hpsc, hence the need for separate documentation.
>
> The hardware supports C22 and C45.
>
> The documentation recommends an input clock of 156.25MHz and a prescaler
> of 39, which yields an MDIO clock of 1.95MHz.
>
> The hardware supports an interrupt pin to signal transaction completion
> which is not strictly needed as the software can also poll a "TRIGGER"
> bit for this.
>
> Signed-off-by: Charles Perry <charles.perry@microchip.com>
> ---
> .../net/microchip,pic64hpsc-mdio.yaml | 61 +++++++++++++++++++
> 1 file changed, 61 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
> new file mode 100644
> index 000000000000..21c76199c11b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
> @@ -0,0 +1,61 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/microchip,pic64hpsc-mdio.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip PIC64-HPSC/HX MDIO controller
> +
> +maintainers:
> + - Charles Perry <charles.perry@microchip.com>
> +
> +description: |
> + Microchip PIC64-HPSC/HX SoCs have two MDIO bus controller. This MDIO bus
> + controller supports C22 and C45 register access. It is named "MDIO Initiator"
> + in the documentation.
> +
> +allOf:
> + - $ref: mdio.yaml#
> +
> +properties:
> + compatible:
> + oneOf:
> + - const: microchip,pic64hpsc-mdio
> + - items:
> + - const: microchip,pic64hx-mdio
> + - const: microchip,pic64hpsc-mdio
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + clock-frequency: true
Does this genuinely have no constraints?
> +
> + interrupts:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + bus {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + mdio@4000C21E000 {
> + compatible = "microchip,pic64hpsc-mdio";
> + reg = <0x400 0x0C21E000 0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + phy0: ethernet-phy@0 {
> + reg = <0>;
> + };
> + };
> + };
> --
> 2.47.3
>
On Wed, Mar 18, 2026 at 05:48:08PM +0000, Conor Dooley wrote: > On Tue, Mar 17, 2026 at 11:46:09AM -0700, Charles Perry wrote: > > This MDIO hardware is based on a Microsemi design supported in Linux by > > mdio-mscc-miim.c. However, The register interface is completely different > > with pic64hpsc, hence the need for separate documentation. > > > > The hardware supports C22 and C45. > > > > The documentation recommends an input clock of 156.25MHz and a prescaler > > of 39, which yields an MDIO clock of 1.95MHz. > > > > The hardware supports an interrupt pin to signal transaction completion > > which is not strictly needed as the software can also poll a "TRIGGER" > > bit for this. > > > > Signed-off-by: Charles Perry <charles.perry@microchip.com> > > --- > > .../net/microchip,pic64hpsc-mdio.yaml | 61 +++++++++++++++++++ > > 1 file changed, 61 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml > > > > diff --git a/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml > > new file mode 100644 > > index 000000000000..21c76199c11b > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml > > @@ -0,0 +1,61 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/net/microchip,pic64hpsc-mdio.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Microchip PIC64-HPSC/HX MDIO controller > > + > > +maintainers: > > + - Charles Perry <charles.perry@microchip.com> > > + > > +description: | > > + Microchip PIC64-HPSC/HX SoCs have two MDIO bus controller. This MDIO bus > > + controller supports C22 and C45 register access. It is named "MDIO Initiator" > > + in the documentation. > > + > > +allOf: > > + - $ref: mdio.yaml# > > + > > +properties: > > + compatible: > > + oneOf: > > + - const: microchip,pic64hpsc-mdio > > + - items: > > + - const: microchip,pic64hx-mdio > > + - const: microchip,pic64hpsc-mdio > > + > > + reg: > > + maxItems: 1 > > + > > + clocks: > > + maxItems: 1 > > + > > + clock-frequency: true > > Does this genuinely have no constraints? It's going to divide the input frequency by 2 to 512 (the prescaler is 8 bit long), so assuming an input clock of 156.25 MHz, the bounds are 305KHz to 78MHz. The standard is 2.5MHz. I can add a maximum and minimum here since I do have some validation on this in the driver which will bail out if this is out of bound. Thanks, Charles
On Wed, Mar 18, 2026 at 02:23:23PM -0700, Charles Perry wrote: > > > + > > > + clock-frequency: true > > > > Does this genuinely have no constraints? > > It's going to divide the input frequency by 2 to 512 (the prescaler is 8 > bit long), so assuming an input clock of 156.25 MHz, the bounds are 305KHz > to 78MHz. The standard is 2.5MHz. > > I can add a maximum and minimum here since I do have some validation on > this in the driver which will bail out if this is out of bound. That sounds like a good idea, thanks. pw-bot: changes-requested Cheers, Conor.
On Thu, Mar 19, 2026 at 01:35:52AM +0000, Conor Dooley wrote: > On Wed, Mar 18, 2026 at 02:23:23PM -0700, Charles Perry wrote: > > > > + > > > > + clock-frequency: true > > > > > > Does this genuinely have no constraints? > > > > It's going to divide the input frequency by 2 to 512 (the prescaler is 8 > > bit long), so assuming an input clock of 156.25 MHz, the bounds are 305KHz > > to 78MHz. The standard is 2.5MHz. > > > > I can add a maximum and minimum here since I do have some validation on > > this in the driver which will bail out if this is out of bound. Hello Conor, I have second doubt about this. The minimum and maximum depend on the input clock frequency which might change if someone uses a different crystal or clock config. So for that reason, I thinks it's better to not specify the bounds, because there's no way to know for sure what they when building the device tree. I will however add a "default: 2500000" following some discussions with Andrew Lunn. Thanks, Charles > > > That sounds like a good idea, thanks. > > pw-bot: changes-requested > > Cheers, > Conor.
On Mon, Mar 23, 2026 at 06:38:06AM -0700, Charles Perry wrote: > On Thu, Mar 19, 2026 at 01:35:52AM +0000, Conor Dooley wrote: > > On Wed, Mar 18, 2026 at 02:23:23PM -0700, Charles Perry wrote: > > > > > + > > > > > + clock-frequency: true > > > > > > > > Does this genuinely have no constraints? > > > > > > It's going to divide the input frequency by 2 to 512 (the prescaler is 8 > > > bit long), so assuming an input clock of 156.25 MHz, the bounds are 305KHz > > > to 78MHz. The standard is 2.5MHz. > > > > > > I can add a maximum and minimum here since I do have some validation on > > > this in the driver which will bail out if this is out of bound. > > Hello Conor, > > I have second doubt about this. The minimum and maximum depend on the input > clock frequency which might change if someone uses a different crystal or > clock config. So for that reason, I thinks it's better to not specify the > bounds, because there's no way to know for sure what they when building the > device tree. Okay, sure.
© 2016 - 2026 Red Hat, Inc.